テストできないコードは、本当にイライラします。次のことが oo-code をテスト不可能にします:
- グローバルな状態、例: シングルトン デザイン パターン
- データベースアクセスなどの凝った作業を行う静的メソッド
- 深い継承ツリー
- 制御ステートメントなどのコンストラクターでの作業
- 単一責任原則に違反するクラス
さらに警告サインはありますか?
テストできないコードは、本当にイライラします。次のことが oo-code をテスト不可能にします:
さらに警告サインはありますか?
これらのどれも、コードをテスト不可能にするものではありません。エッジ ケースのバグを見つけるのが難しくなる可能性がありますが、テストの成功基準を完全に指定している (そしてテスト駆動開発がこれを容易にしている) 場合は、基準に合格するだけで済みます。
TDD はプロジェクト全体だけでなく、特定の部分の動作にも適用できるため、非常に小さなコンポーネントを簡単にテストできます。ただし、これは結果をテストするためのものであり、結果が得られた手段をテストするためのものではありません。
テストに合格すれば、要件を満たしたことになります。それに続いてバグがある場合、これはテストされているコードではなく、テストの問題です (この場合、以前に予期されなかった問題をキャッチするためにテストを変更する必要があります)。
コンストラクターの 1 つに while ステートメントがあるかどうか (機能の提供に関して) 気にする必要はありません。どのビジネス要件でそれが義務付けられているかを自問する必要があります。あなたのクライアントが「継承は 4 レベルに制限されている」などの要件のリストを提出するとは思えません。彼らは要件として「バグフリー」を挙げているかもしれませんが、それについては交渉する必要があります:-)。
Miško Hevery による次のブログ投稿を参照してください: How to Write 3v1L, Untestable Code .
ハードコーディングされた依存関係。
プレゼンテーションとは関係のない GUI クラスで行われる作業。GUI は、基礎となるモデルから完全に分離する必要があります。
コードは、変更できない限りテストできません。プロジェクトをリファクタリングする可能性がある場合、テストできないコードはありません。通常、テストを容易にするために必要な変更はごくわずかです。また、コードの品質が向上するため、正当化できます。
あなたが説明した場合でも、コードは必ずしもテスト不可能ではありません。テストが難しくなるだけです。たとえば、単体テスト中にデータベース アクセスを分離して回避できれば、コードのテストが容易になります。ただし、必要に応じて、テストの実行専用のデータベースを作成できます。
これらのどれも、コードをテスト不可能にするものではないと思います。それらのそれぞれが実装の結合を増加させるため、単体テストが困難になります。
単体テストを困難にするその他の煩わしさには、次のようなものがあります。
一般に、より優れたコードの作成に関する推奨事項は、コードの単体テストを容易にするための推奨事項でもあります。
テスト可能なコードの記述に関する Miško Hevery のガイドでは、コードのテストを困難にする欠陥について詳しく説明しています。彼のリストはあなたのリストと多少重複していますが、信じられないほど詳細になっています。
データベース!特にトリガーのあるもの!
データベースをモックできることは知っていますが、私のコード (主に CRUD アプリ) のバグのほとんどはデータ/マッピングの問題であり、データベースをモックしてもそのようなバグは見つからないことが常にわかっています。
階層化の欠如、結合の過剰...つまり、クラス Y は X について知るように書かれていますが、そうすべきではありません。X は再利用可能です。テスト容易性と再利用可能性の間には強い関係があります。