[解決済み] 良いユニットテストとは？[クローズド］

質問

皆さんの多くは多くの自動テストを書いており、ユニットテストの際にいくつかの共通の落とし穴に遭遇していることでしょう。

私の質問は、将来的に問題を避けるために、テストを書くための行動規則に従っていますか？より具体的に言うと 具体的には 良いユニットテストの特性は何ですか？ あるいは、どのようにテストを書けばいいのでしょうか？

言語にとらわれない提案が望まれます。

どのように解決するのですか？

まず、ソースを差し込むところから始めましょう -。 JUnitを使ったJavaの実用的なユニットテスト (C#-Nunitを使ったバージョンもありますが、私はこれを持っています...ほとんどの部分において不可知論です。おすすめです)。

良いテストは 旅行 (この頭文字は十分な粘着性がありません。私は本の中のチートシートをプリントアウトして、これが正しいことを確認するために引っ張り出してきました...)

• 自動 : テストの起動やPASS/FAILのチェックは自動であるべきです。
• 徹底的な : カバレッジ： バグはコードの特定の領域に集中する傾向がありますが、すべての主要なパスとシナリオをテストすることを確認します。テストされていない領域を知るために必要であれば、ツールを使用する。
• 繰り返し可能 : テストは毎回...毎回、同じ結果を出すべきです。テストは制御不能なパラメータに依存すべきではありません。
• 独立した : 非常に重要です。
  • テストは 1つのことだけをテストする でなければなりません。複数のアサーションがあっても、それらがすべてひとつの機能/振る舞いをテストしている限りは問題ありません。テストが失敗するとき、問題の場所をピンポイントで特定する必要があります。
  • テスト は互いに依存してはいけません。 - 孤立している。テスト実行の順序を仮定しない。セットアップ/ティアダウンを適切に使用し、各テストの前に「白紙の状態」を確保する。

• プロフェッショナル : 長い目で見れば、実運用コードと同じくらい（それ以上でないとしても）多くのテストコードがあるはずです。したがって、テストコードのための優れた設計の同じ基準に従います。よくファクタリングされたメソッド、意図を明らかにする名前を持つクラス、重複のない、良い名前を持つテスト、などです。

• 良いテストも実行する 速い 実行に0.5秒以上かかるようなテストは、取り組む必要があります。テストスイートの実行に時間がかかればかかるほど、実行される頻度が少なくなります。開発者が実行の間にこっそり変更しようとすればするほど、何かが壊れれば、どの変更が原因であるかを見つけ出すのに時間がかかるでしょう。

2010-08 に更新しました。

• 読み取り可能 : これはプロフェッショナルの一部と考えることができますが、十分に強調することはできません。テストは、あなたのチームの一員ではない誰かを見つけ、その人に数分以内にテスト中の動作を理解するように頼むことです。テストはプロダクションコードと同じようにメンテナンスされる必要がある - だから、より多くの努力が必要だとしても、読みやすくすること。テストは対称的（パターンに従う）かつ簡潔（一度に一つの動作をテストする）であるべきです。一貫した命名規則 (例: TestDox スタイル) を使用しましょう。テストに付帯する詳細な情報を盛り込まないようにしましょう。

これらを除けば、他のほとんどは利益の少ない作業を削減するためのガイドラインです。例えば、「自分が所有していないコード（サードパーティのDLLなど）はテストしないこと」です。ゲッターやセッターのテストに手を出すな。コスト・ベネフィット比や欠陥確率に目を配る。