単体テストアンチパターンカタログ

アンチパターン：実際のアンチパターンを単純な悪い習慣、悪い習慣、悪い考えから正式に区別するには、少なくとも2つの重要な要素が存在する必要があります。

• 最初は有益であるように見えるが、最終的には有益な結果よりも悪い結果をもたらす、繰り返される行動パターン、プロセスまたは構造
• 明確に文書化され、実際の実践で実証され、再現可能なリファクタリングされたソリューション。

「実際に」一度見たTDDアンチパターンに投票してください。
James Carrによるブログ投稿と テスト駆動開発yahoogroupに関する関連ディスカッション

名前のないものを見つけた場合は、投稿してください。アンチパターンごとに1つの投稿をして、投票が何かにカウントされるようにしてください。

私の既得権は、トップnのサブセットを見つけることです。そうすれば、近い将来、ランチボックスのミーティングで話し合うことができます。

セカンドクラスの市民 -テストコードは、複製されたコードを多く含む本番コードほどリファクタリングされていないため、テストを維持することが困難です。

フリーライド/ピギーバック-James Carr、Tim Ottinger 別の/明確な機能/機能
をテストするための新しいテストケースメソッドを記述するのではなく、新しいアサーション（およびそれに対応するアクション、つまりAAAからのActステップ）が既存のテストケースに沿って動作します。 。

ハッピーパス

テストは、境界や例外をテストすることなく、ハッピーパス（つまり、期待される結果）を維持します。

JUnitアンチパターン

ローカルヒーロー

実行するために記述された開発環境に固有の何かに依存するテストケース。その結果、テストは開発ボックスに合格しますが、他の場所で実行しようとすると失敗します。

隠された依存関係

ローカルヒーローと密接に関連する単体テスト。テストを実行する前に、既存のデータをどこかに入力しておく必要があります。そのデータが入力されていなかった場合、テストは失敗し、開発者には何が必要か、またはその理由はほとんど示されません。使用しているデータの出所がどこにあるかを見つけるために、何エーカーものコードを掘り下げることを強制します。

残念なことに、特定のプロダクションシステムで常に同期されていない曖昧で多様な.iniファイルに依存する古代の.dllでこれを何度も見ました。はぁ。

チェーンギャング

特定の順序で実行する必要があるいくつかのテスト。つまり、1つのテストがシステムのグローバル状態（グローバル変数、データベース内のデータ）を変更し、次のテストがそれに依存します。

これはデータベーステストでよく見られます。でロールバックを実行する代わりにteardown()、テストは変更をデータベースにコミットします。別の一般的な原因は、グローバル状態への変更が、テストが失敗した場合にクリーンアップするtry / finallyブロックにラップされないことです。

嘲笑は
時には良い、と便利なことができあざけります。しかし、時々、開発者は自分自身を失い、テストされていないものをあざけるために努力することができます。この場合、単体テストには非常に多くのモック、スタブ、および/または偽物が含まれているため、テスト対象のシステムはまったくテストされていません。代わりに、モックから返されるデータがテスト対象です。

出典：James Carrの投稿。

サイレントキャッチャー -ケリー？
例外がスローされた場合にパスするテスト。実際に発生する例外が、開発者が意図したものとは異なる場合でも。
参照：シークレットキャッチャー

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}

インスペクター
100％のコードカバレッジを達成するためにカプセル化に違反するユニットテストですが、オブジェクトで何が行われているのかを十分に理解しているため、リファクタリングを試みると既存のテストが中断され、変更をユニットに反映する必要があります。テスト。

'メンバー変数を公開せずにテストするにはどうすればいいですか... 単体テストのためだけですか？'

過剰なセットアップ -James Carr
テストを開始するためにも、大規模なセットアップが必要なテスト。場合によっては、数百行のコードを使用して、1つのテスト用に環境を準備し、いくつかのオブジェクトが関係しているため、すべてのセットアップの「ノイズ」が原因で、何がテストされているかを実際に確認することが困難になる場合があります。（Src：James Carrの投稿）

肛門プローブ

次のようなタスクを実行するためにめちゃくちゃ、違法、またはその他の不健全な方法を使用する必要があるテスト：JavaのsetAccessible（true）を使用してプライベートフィールドを読み取るか、クラスを拡張して保護されたフィールド/メソッドにアクセスするか、アクセスするために特定のパッケージにテストを配置する必要がありますグローバルフィールド/メソッドをパッケージ化します。

このパターンが見られる場合、テスト中のクラスはデータの隠蔽を使いすぎています。

これとインスペクターの違いは、テスト中のクラスが、テストする必要があるものでさえも隠そうとすることです。したがって、目標は100％のテストカバレッジを達成することではなく、何でもテストできるようにすることです。プライベートフィールドのみを持つクラス、run()引数なしのメソッド、ゲッターがまったくないクラスを考えてみてください。ルールを破ることなくこれをテストする方法はありません。

Michael Borgwardtによるコメント：これは実際にはテストのアンチパターンではなく、テストされるコードの欠陥に対処するのは実用的です。もちろん、これらの欠陥を修正することをお勧めしますが、サードパーティのライブラリの場合はそれができない場合があります。

Aaron Digulla：同意します。たぶん、このエントリはアンチパターンではなく「JUnit HOWTO」wikiに本当に適しています。コメント？

名前のないテスト -Nick Pellow

バグトラッカーの特定のバグを再現するために追加され、その作者が自身の名前を正当化しないと考えるテスト。既存の不足しているテストを拡張する代わりに、testForBUG123という新しいテストが作成されます。

2年後、そのテストが失敗した場合、テストの意図を理解するために、まずバグトラッカーでBUG-123を試してみる必要があるかもしれません。

スローポケ

実行速度が非常に遅い単体テスト。開発者がそれを開始するとき、彼らはトイレに行く時間、煙をつかむ時間、さらに悪いことに、一日の終わりに家に帰る前にテストを開始する時間があります。（Src：James Carrの投稿）

別名、必要以上に頻繁に実行されないテスト

バタフライ

現在の日付を含む構造のように、常に変化するデータを含む何かをテストする必要があり、結果を固定値に限定する方法はありません。醜い部分は、この値をまったく気にしないことです。値を追加せずにテストを複雑にするだけです。

その翼のバットは、世界の反対側にハリケーンを引き起こす可能性があります。-エドワード・ローレンツ、バタフライエフェクト

ちらつきテスト（出典：Romilly Cocking）

特定の時間ではなく、たまに失敗するテストで、通常はテスト内の競合状態が原因です。通常、JMSなどの非同期なものをテストするときに発生します。

おそらく、「待機して参照」アンチパターンと「スリーパー」アンチパターンのスーパーセットです。

ビルドは失敗しました。まあ、もう一度ビルドを実行してください。-匿名の開発者

成り行きを見守る

セットアップコードを実行し、テスト中のコードが期待どおりに機能したかどうかを「確認」する前に、特定の時間「待機」する必要があるテスト。Thread.sleep（）または同等のものを使用するtestMethodは、間違いなく「待機して参照」テストです。

通常、テストが、電子メール、http要求などのシステム外部のイベントを生成したり、ディスクにファイルを書き込んだりするコードをテストしている場合に、これが表示されることがあります。

このようなテストは、低速のマシンまたは過負荷のCIサーバーで実行すると失敗するため、ローカルヒーローになる可能性もあります。

Wait and SeeアンチパターンをThe Sleeperと混同しないでください。

不適切に共有されたフィクスチャ -Tim Ottinger
テストフィクスチャ内のいくつかのテストケースは、セットアップ/ティアダウンを使用しないか、必要としません。新しいテストフィクスチャを作成する開発者の慣性によるものもあります...もう1つテストケースをパイルに追加する方が簡単です。

巨人

ユニットテストは、テスト対象のオブジェクトを有効にテストしていますが、数千行におよび、多数のテストケースを含むことができます。これは、テスト中のシステムが神オブジェクト（ジェームズカーの投稿）であることを示している可能性があります。

これの確実な兆候は、数行を超えるコードにまたがるテストです。多くの場合、テストは非常に複雑なので、独自のバグや不安定な動作のバグが含まれ始めます。

私が見たとき、私はそれを信じていますいくつかの点滅のGUI
アン不健康な固定/固定観念ただ実際のユーザーのように'は、そのGUIを介してアプリケーションをテストすると

GUIを介してビジネスルールをテストすることは、恐ろしい形の結合です。GUIを介して数千のテストを記述し、その後GUIを変更すると、数千のテストが失敗します。
むしろ、GUIを介してGUIのものだけをテストし、それらのテストを実行するときに、GUIを実際のシステムではなくダミーシステムに結合します。GUIを使用しないAPIでビジネスルールをテストします。-ボブ・マーティン

「あなたは見ることは信じることであることを理解しなければなりませんが、信じることは見ることであることも知っています。」- デニスウェイトリー

スリーパー、別名ベスビオ山 -Nick Pellow

将来の特定の日時にFAILになる予定のテスト。これは多くの場合、DateオブジェクトまたはCalendarオブジェクトを使用するコードをテストする際の不正な境界チェックが原因で発生します。場合によっては、真夜中などの特定の時刻に実行すると、テストが失敗することがあります。

「スリーパー」を「待機して参照」アンチパターンと混同しないでください。

そのコードは2000年よりずっと前に置き換えられます -1960年の多くの開発者

死んだ木

スタブが作成されたが、実際にはテストが記述されていないテスト。

私は実際にこれを製品コードで見ました：

class TD_SomeClass {
  public void testAdd() {
    assertEquals(1+1, 2);
  }
}

私はそれについてどう考えるべきかさえ知りません。

今日これで少し得た：

ウェットフロア：
テストはどこかに保持されるデータを作成しますが、テストは終了時にクリーンアップしません。これにより、後続のテスト実行でテスト（同じテスト、または場合によっては他のテスト）が失敗します。

私たちの場合、テストでは、最初にテストを実行したユーザーからのアクセス許可を使用して、「temp」ディレクトリにファイルが残っています。別のユーザーが同じマシンでテストしようとしたとき：ブーム。James Carrのサイトのコメントで、Joakim Ohlroggeはこれを「ずさんな労働者」と呼び、「寛大な残り物」のインスピレーションの一部でした。自分の名前の方が好きです（侮辱的でなく、より親しみやすい）。

カッコウ -フランクカーバー
テストケースに他の何人かと一緒に座って、テストケースの他のテストと同じ（長くなる可能性がある）セットアッププロセスを享受しますが、セットアップからのアーティファクトの一部またはすべてを破棄します独自のものを作成します。
の高度な症状：不適切に共有されたフィクスチャ

シークレットキャッチャー -フランクカーバー
アサーションがないため、一見するとテストを行っていないように見えるテスト。しかし、「悪魔は詳細にあります」..テストは実際には例外がスローされることに依存しており、テストフレームワークが例外をキャプチャしてユーザーに失敗として報告することを期待しています。

[Test]
public void ShouldNotThrow()
{
   DoSomethingThatShouldNotThrowAnException();
}

環境破壊者

さまざまな「要件」について、環境変数/ポートを使用および設定する「ユニット」テストがその環境に流出し始めます。これらのテストのうち2つを同時に実行すると、「利用できないポート」の例外などが発生します。

これらのテストは断続的に行われ、開発者は「もう一度実行する」などと言ってしまいます。

私が見た1つの解決策は、使用するポート番号をランダムに選択することです。これは競合の可能性を減らしますが、明らかに問題を解決しません。したがって、可能であれば、コードをモックして、共有できないリソースを実際に割り当てないようにしてください。

チューリングテスト

非常に巧妙なデータフロー分析を使用して、テスト対象のクラスから多数のアサートを収集する高価なツールによって自動的に生成されたテストケース。開発者をコードが十分にテストされているという誤った自信に陥らせ、高品質のテストを設計および維持する責任から解放します。マシンがあなたのためにテストを書くことができるなら、なぜそれがその指を引き出してアプリ自体を書くことができないのですか？

バカこんにちは。-世界で最もスマートなコンピューターから新しい弟子（古いAmigaコミックまで）。

40フィートポールテスト

テストしようとしているクラスに近づきすぎることを恐れて、これらのテストは、数え切れないほどの抽象化レイヤーとチェックしているロジックからの数千行のコードによって隔てられた距離で動作します。そのため、それらは非常に壊れやすく、興味のあるクラスとの間の壮大な旅で発生するあらゆる種類の副作用の影響を受けます。

ドッペルゲンガー

何かをテストするには、テスト中のコードの一部を同じ名前とパッケージの新しいクラスにコピーする必要があり、クラスパスマジックまたはカスタムクラスローダーを使用して、最初に表示されることを確認する必要があります（そのため、コピーが選択されます）アップ）。

このパターンは、テストからは制御できない、異常な量の隠れた依存関係を示しています。

私は彼の顔を見た…私の顔！鏡のようでしたが、血が凍りました。

母編 -フランクカーバー
実際のテストケースが必要とするよりもはるかに多くを行う一般的な設定。たとえば、テストが何かの存在または不在についてのみアサートするときに、明らかに重要で一意の値が入力されたあらゆる種類の複雑なデータ構造を作成します。
高度な症状：不適切に共有されたフィクスチャ

私はそれが何をするのかわからない...念のためにとにかくそれを追加しています。-匿名の開発者

すべてをテストする

これが今まで言及されていなかったとは信じられませんが、テストは単一責任の原則を破るべきではありません。

私はこれに何度も遭遇しました。このルールに違反するテストは、定義上、維持するのが悪夢です。

ラインヒッター

一見すると、テストはすべてをカバーし、コードカバレッジツールはそれを100％で確認しますが、実際のテストでは、出力分析なしでコードのみをヒットします。

カバレッジ対到達可能コード