ブログ

Unit Test Smells

テストが何もテストしていない

一見するとテストが有効に機能しているように見えるが、実はテスト対象をテストしていない

テストに過度なテスト準備が必要とされる

テストが環境をセットアップするのに長いコードを必要としている。こういうノイズがテストが本当にテストしたいのが何なのか？ということを分かりにくくする。

大きすぎるテスト

有用だが大きすぎるテスト。たぶんテストが１つではなく複数の機能をチェックしているか、テストが１つ以上のことをやろうとしている(単一責任の原則に反している)

内部をチェックしている

テストがテスト対象のコードの内部メソッド(privateやprotectedのメソッド)にまでアクセスしている。これはリファクタリングしにくくなる。

テストは開発者のマシンでしか動かない

テストが開発環境のみで動作し他で動かない。こういう問題をできる限り早期に発見するため、継続的インテグレーションを利用すること。

テストが必要以上のことをチェックしている

テストが熱心という以上にチェックしている。こういうテストは本来チェックする必要のない箇所をちょっと変えただけで失敗することになってしまう。特にモックを利用していたり、ソートされていないコレクションの並び順をチェックするようなことをしていると発生しやすい。

アサーションの欠如

テストが何もアサーションを使っていない

チャットみたいなテスト

コンソールをテキストで埋めてしまうようなテスト。たぶん何かのチェックを手動で行うために使われているんだろう。。。

例外を飲み込んでしまったテスト

テストが例外をキャッチして握り潰しテストを通している

テストがテスト用のfixtureと紐づいていない

陳腐化したテスト

既にシステムで必要とされていない項目をチェックしている。そういうコードが参照されていると綺麗なプロダクションコードにすることが妨げられる

テスト内容が隠されている

テスト内容がセットアップメソッドや基底クラスやヘルパークラスに書かれている。テストはテストメソッドを見るだけで何をテストしているか把握可能であるべきである。テストは他の場所で初期化したりアサーションしたりしてはいけない。

振る舞いとアサーションの混合

コードの実行結果をアサーションでチェックしている。最初にテスト対象のコードを実行してローカル変数に代入し、その値をアサーションでチェックしている。

失敗した理由がわからない

テストを分割するかアサーションメッセージを使う必要がある。

条件分岐のテストロジック

テストの中では条件分岐によるテストロジックは組み込むべきではない。そうしてしまうとテストが読みにくくなる。

製品コードの中にテストロジックがある

テストが製品コード内の特殊ロジックに依存している。

不安定なテスト

時々はテストに通るが、時々は環境等の理由で失敗する

TDD Process Smells

ここ10分でGreenのバーを見ていない

できる限り素早い頻繁なフィードバックを得るためには、小さいステップで進める必要がある。

製品コードを書く前にテストを動かしていない

テストに失敗して初めて製品コードが必要となる。さらに驚くことにテストが失敗しなかったら、テストが本当に正しいのか確認すること。

リファクタリングに十分な時間を使っていない

リファクタリングは将来への投資である。可読性、変更容易性、拡張性となって返ってくる

テストするのが簡単すぎるものを飛ばす

想定ではなくてチェックすべきだ。もし機能が簡単ならテストもより簡単なんだから。

テストするのが難しすぎるものを飛ばす

よりシンプルにすること。さもないとバグが混入し、保守性が下がる。

振る舞いではなくてメソッド中心にテストを構成している

メソッドのテストは壊れやすくリファクタリングキラーだ。テストは実際に使われる機能の小さなユースケースをテストすること。

コードカバレージをゴールにする

コードカバレージを不足しているテストの発見に使うこと。さもないとコードカバレージは増えたけれども不確かな役に立たないテストが増えたということになりかねない。