単体テストを行わないのはいつが適切ですか?


138

私は小さな会社でソロ開発者として働いています。私は実際に会社で唯一の開発者です。定期的に書いて保守しているいくつかの(比較的)大規模なプロジェクトがあり、それらをサポートするテストはありません。新しいプロジェクトを始めるとき、TDDアプローチを試してみるべきかどうかとよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。

私は自分のデザインを前向きに考えようと努力しています。いつか別の開発者がコードを保守するか、少なくともトラブルシューティングを行う必要があることは確かです。できる限りシンプルなものにし、把握するのが難しいものをコメントして文書化します。そして実際、これらのプロジェクトはそれほど大きくも複雑でもないので、まともな開発者は理解するのに苦労するでしょう。

私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。そうでなければビジネスニーズの解決に費やすことができる時間。

そのため、毎回同じ結論に達します。投資収益率が低すぎます。

私は時折、雇用日に基づいて誰かが会社にいた年数を計算するなど、アルゴリズムを正しく記述したことを確認するために、いくつかのテストを設定しました。しかし、コードカバレッジの観点からは、コードの約1%をカバーしています。

私の状況では、ユニットテストを定期的に行う方法をまだ見つけることができますか、それともそのオーバーヘッドを回避することを正当化できますか?

更新: 除外した私の状況に関するいくつかのこと:私のプロジェクトはすべてWebアプリケーションです。すべてのコードをカバーするには、自動化されたUIテストを使用する必要がありますが、それは手動テストよりも大きなメリットが見られない領域です。


1
みんな、ありがとう。ここで多くを学んでいます。私が除外した私の状況に関するいくつかのこと:私のプロジェクトはすべてWebアプリケーションです。すべてのコードをカバーするには、自動化されたUIテストを使用する必要がありますが、それは手動テストよりも大きなメリットが見られない領域です。
ケンペスピサ

1
TelerikのWeb自動テストツールを使用して、Transactisで大きな成功を収めています。私たちはすでに、以前は手動で行っていたブラウザテストを自動化に変換しました。自動化されたテストは非常に高速であり、Webサイトで発生する可能性のあるパフォーマンスの問題を強調するのにも最適です。
ジョン・キャスター

2
完全なWebページの自動ブラウザテストを試みたプロジェクトを見ました。私が知る限り、手動テストで見つかった数百の重大なバグは見つかっておらず、開発と保守に膨大な時間を要しました。(NUnitによって駆動されるSeleniumを使用)。さらに悪いことに、ブラウザとテストフレームワークの非互換性のために、問題のないテストが頻繁に壊れます。
オルーニー

1
これは実際には答えではなく、単なる観察です...「要件が頻繁に変更される」ため、ユニットテストに対するあなたの議論は、私が働いている場所で聞いている逆の議論を思い出させます:「私たちのプログラムはとても静的です、テストのポイントは何ですかとにかくほとんど変わらない!」;)
ベイン14年

2
Webアプリケーションの自動化されたUIテストは単体テストではありません。それらはまったく異なるものであり、それらを実行したくない場合でも私はあなたを責めません。ただし、ビジネスコードはすべてバックエンドに配置する必要があり、それをテストする必要があります。
ニャミオウガレアンスロペ

回答:


84

私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。

そう?すべてをテストする必要はありません。関連するものだけ。

私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。

それは実際には間違っています。より効率的ではありません。それは本当にただの習慣です。

他のソロ開発者は、スケッチまたはアウトラインを作成し、テストケースを作成してから、アウトラインに最終コードを入力します。

それは非常に効率的です。

また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。

それも間違っています。テストはドラッグではありません。要件の変更はドラッグです。

要件を反映するようにテストを修正する必要があります。それらの特徴点、または高レベル; 最初に書き込まれるか、最後に書き込まれます。

テストに合格するまで、コードは実行されません。それがソフトウェアの唯一の普遍的な真実です。

限定的な「ここにある」受け入れテストを行うことができます。

または、いくつかの単体テストを使用できます。

または、両方を持つことができます。

しかし、あなたが何をしても、ソフトウェアが機能することを実証するテストは常にあります。

少し形式的で素晴らしき単体テストツールスイートがあれば、そのテストははるかに便利になると思います。


8
関連するものだけをテストする最初の声明が好きです。手動テストと単体テストの効率に関しては、私の声明が完全に間違っているとは思いません。最大の効率を達成するために、自動テストと手動テストの間にバランスが見られるようです。
ケンペスピサ

9
@Ken Pespisa:ごめんなさい。TDD Kool-Aidを飲んだのは約2年前(テストの30年後)です。今、私はテストファーストにこだわっています。構築する際に考えていることがあまりないので、ずっと生産的になりました。
-S.ロット

3
@Ken Pespisa:いいえ。答えにはバランスがあります。ゼロで除算するのが正しいかどうかを尋ねると、理由がある理由で一方的に傾いている圧倒的な反応を得るでしょう。sqrt(-1)整数かどうかを尋ねた場合、一方向に傾いた圧倒的な応答が得られます。バランスは、「方法」と「順序」に依存します。裸の事実は、テストする必要があるということです。したがって、最初にテストを記述し、それらが機能することを確認してください。
-S.ロット

21
実装の詳細ではなく、インターフェイスの単体テストを検討してください。制限と境界ケースをテストします。危険なコードをテストします。コードの検査は他の人のコードの検査よりもエラーが発生しやすいものの、多くのコードは検査によって検証するのに十分簡単です。初めての手動テストの方が効率的である可能性があります。10回目の自動テストはこれからです。
-BillThor

10
「テストに合格するまでコードは実行されません」-そうではない、IMO。コード、テストに合格すると開始されます。コードは、1〜2年稼働し、ストレステストと、大規模でアクティブで短気なユーザーベースとの統合テストの対象となるまで実行されません。それが本当に重要な唯一のテストです。
ベクトル

107

瞬きで実行でき、緑または赤のライトが点灯する一連のテストがあると想像してください。この一連のテストがすべてをテストしたと想像してください!テストスイートを実行するために必要な作業は、^ Tと入力するだけであったと想像してください。これはあなたにどんな力を与えますか?

何かを壊すことを恐れずにコードを変更できますか?古い機能を壊すことを恐れずに新しい機能を追加できますか?損傷を恐れずに、乱雑なコードをすばやくクリーンアップできますか?

はい、それらすべてを行うことができます!そして、時間の経過とともにコードはどうなりますか?それをきれいにするリスクがないので、それはますますきれいになります。

肩に小さな妖精がいると想像しましょう。あなたがコード行を書くたびに、妖精はテストスイートに何かを追加し、そのコード行が意図したとおりに動作することをテストします。そのため、数秒ごとに^ Tを押して、書いたコードの最後の行が機能したことを確認できます。

どのくらいのデバッグを行うと思いますか?

これが幻想のように聞こえるなら、あなたは正しい。しかし、現実はそれほど変わりません。まばたきを数秒で、妖精をTDDの規律で置き換えれば、ほぼ完成です。

1年前に構築したシステムに戻ってきて、中心オブジェクトの1つを作成する方法を忘れたとしましょう。そのオブジェクトを作成できるあらゆる方法で作成するテストがあります。これらのテストを読んで、記憶をジョギングできます。APIを呼び出す必要がありますか?呼び出し可能なすべての方法でそのAPIを呼び出すテストがあります。これらのテストは、理解できる言語で書かれた小さなドキュメントです。それらは完全に明確です。それらは非常に形式的であるため、実行されます。そして、彼らはアプリケーションと同期を取ることができません!

投資する価値がない?あなたは私をからかっていなければならない!誰もそのテストスイートを望まないでしょうか?自分に賛成して、愚かなことを口論するのをやめてください。TDDを上手に行う方法を学び、どれだけ速くなるか、コードがどれだけきれいになるかを見てください。


28
おじさん、ボブおじさん?ここであなたの考えを得るのは素晴らしいことです。TDDの利点については同意しますが、実際に議論する必要はありません。問題は、時間とROIの投資についてです。これらのことを考えるのは愚かではありません。プロジェクトがTDDを使用するよりも50%時間がかかる場合を想像してください。また、プロジェクトの存続期間中、手動テストよりも10%の時間しか節約できないと妖精は言います。それは幻想のように思えるかもしれませんが、特定のプロジェクトでは完全にもっともらしいと思います。
ケンペスピサ

11
@Ken「プロジェクトを想像すると、TDDを使用するよりも50%時間がかかる場合があります」。それはまさに私にとって幻想のように聞こえます。実際、あなたはそれを裏付ける証拠の断片なしに、その場でその姿を作り上げたようです。
ラインヘンリヒス

18
@Rein Henrichs-もちろん数字を作り上げた、それは仮説的な声明だった。私は、TDDがプロジェクトにかなりの時間を追加することを強調しています。そして、見返りに同等以上の価値を得るかどうかを検討する必要があります。TDDの価値について私を納得させる必要はありません、私は確信しています。しかし、万能薬ではありません。
ケンペスピサ

11
@Rein、「利用可能な証拠」とは正確には何ですか?詳しく説明してください。
ケンペスピサ

22
@Uncle Bob「まばたきを数秒で置き換えてください」:もちろん冗談です。TDDは優れたツールですが、関連する部分のみをテストする必要があります。そうしないと、深刻な開発を行うよりもテストの維持に多くの時間を費やすことになります。これは、要件が非常に急速に変化する場合に特に当てはまります。常に変化するクラスのテストを絶えず書いて捨てています。私はTDDが悪いと言っているわけではありません。それは賢明に使用されなければならず、あなたが示唆するように機械的に適用されるべきではありません。
ジョルジオ

34

あなたが犯している間違いは、テストが時間的な投資であり、即座に利益をもたらさないことです。必ずしもそのように機能するとは限りません。

最初にテストを書くことは、コードのこの部分が何をする必要があるかに本当に焦点を合わせます。

次に、それらを実行すると、テストで発生するバグが明らかになります。

第三に、それらを実行すると、テストでは発生しなかったバグが表示されることがあり、実稼働環境で実際にあなたに噛みついてしまいます。

第4に、実行中のシステムでバグに遭遇し、そのための単体テストを作成した場合、そのバグを後で再導入することはできません。それは本当に大きな助けになります。再導入されたバグは一般的で非常に迷惑です。

第5に、コードを他の人に引き渡す必要がある場合、テストスイートを使用することで作業がはるかに容易になります。また、プロジェクトを無視して数年後にプロジェクトに戻ってきた場合、そのプロジェクトにそれほど近づかず、あなたにとっても役立つでしょう。

私の経験では、プロジェクトの開発全体を通して、適切な単体テストを行うことで、プロセスが常により速く、より信頼できるものになりました。


2
@Ken、テストスイートは実行形式の仕様です。

32

JUnit(Javaユニットテストフレームワーク)のスタッフは、テストするのが簡単すぎる場合はテストしないという哲学を持ってます。かなり実用的であるため、Best Practices FAQを読むことを強くお勧めします。

TDDは、ソフトウェアを記述する別のプロセスです。単体テストの背後にある基本的な前提は、デバッガーがコードをステップ実行する時間を短縮し、コードの変更がシステムの他の何かを誤って壊しているかどうかをより迅速に把握することです。TDDに適合します。TDDサイクルは次のとおりです。

  1. テストを書く
  2. 失敗するのを見てください(何かする必要があることを証明してください)
  3. テストに合格するために必要なものだけを記述してください。
  4. それが通過するのを見てください(はい!)
  5. リファクタリング(改善する)
  6. 洗浄、すすぎ、繰り返し

TDDを適用することについてそれほど明白ではないのは、コードの記述方法が変わることです。コードが機能していることをテスト/検証する方法について考えるように強制することにより、テスト可能なコードを記述しています。また、ユニットテストについて話しているため、通常はコードがよりモジュール化されることを意味します。私にとって、モジュール式でテスト可能なコードは前もって大きな勝利です。

ここで、C#プロパティなどをテストする必要がありますか?次のように定義されたプロパティを想像してください:

bool IsWorthTesting {get; set;}

この時点で言語機能をテストしているため、答えは「いいえ」で、テストする価値はありません。C#プラットフォームの人たちがそれを正しく実現したと信じてください。また、失敗した場合、それを修正するにはどうすればよいですか?

また、適切にテストするには非常に手間がかかりすぎるコードの特定の部分があることがわかります。それは、それをしないことを意味しますが、トリッキーな問題によって使用される/使用されるコードを必ずテストしてください。

  • インストールが失敗した場合にのみ発生する可能性のあるチェックされた例外。Javaにはこれらがたくさんあります。インストールされたファイルをハッキングせずに失敗する方法がない場合でも、catchブロックを記述するか、チェック済み例外を宣言する必要があります。
  • ユーザーインターフェイス。テスト対象のコントロールを見つけ、適切なイベントを呼び出してユーザーのアクションをシミュレートするのは非常に面倒であり、場合によっては不可能です。ただし、Model / View / Controllerパターンを使用する場合は、モデルとコントローラーがテストされていることを確認し、ビュー部分を手動テストに任せることができます。
  • クライアント/サーバーの相互作用。これはもはや単体テストではなく、統合テストになりました。回線を介してメッセージを送受信するまでのすべての部分を記述しますが、実際には回線を経由しないでください。良いアプローチは、実際の通信で生の通信と通信するコードの責任を減らすことです。ユニットテストコードで、通信オブジェクトをモックアウトして、サービスが期待どおりに動作することを確認します。

信じられないかもしれませんが、TDDは、開発の持続可能なペースへの移行を支援します。それは魔法によるものではなく、タイトなフィードバックループがあり、本当に愚かな間違いをすばやくキャッチできるからです。これらの間違いを修正するコストは基本的に一定です(少なくとも計画の目的には十分です)。小さな間違いは決して大きな間違いには成長しないからです。それを、コードの大暴れ/デバッグパージスプリントのバースト性と比較してください。


24

テストのコストとバグのコストのバランスを取る必要があります。

失敗が「ファイルが見つかりません」であるファイルを開く関数の10行の単体テストを書くことは無意味です。

複雑なデータ構造に対して複雑なことを行う関数-明らかにそうです。

トリッキーなビットは中間にあります。ただし、単体テストの真の価値は特定の機能をテストすることではなく、それらの間の扱いにくい相互作用をテストすることであることを忘れないでください。そのため、1ビットのコードの変更が、1000行離れた別のモジュールの一部の機能を破壊することを発見する単体テストは、コーヒーの中でその価値があります。


23

テストはギャンブルです。

テストの作成は、ユニットで発生し、そのテストでバグをキャッチしない(現在および将来のすべてのコード改訂中)バグのコストが、テストの開発コストよりも大きいという賭けです。これらのテスト開発コストには、追加されたテストエンジニアリングの給与、市場投入までの時間の追加、他のものをコーディングしないことによる機会損失の損失などが含まれます。

他の賭けと同様に、時には勝ち、時には負けます。

バグがはるかに少ない最近のソフトウェアは、最初に市場に出回る迅速だがバグのあるものに勝ちます。時には反対。特定の分野の統計情報と、経営陣がギャンブルしたい金額を確認する必要があります。

いくつかの種類のバグは、統計的には追加の特定のテストを作成する価値がないほど、作成される可能性が非常に低いか、初期の健全性テストから除外される可能性があります。ただし、バグのコストが非常に大きい場合(医療、核など)、企業は負けた賭けをしなければなりません(保険の購入と同様)。多くのアプリはそのような高い失敗コストを持たないため、より高い不経済な保険の適用範囲を必要としません。他の人がします。


3
いい答えだ。私の元の質問に本当に答えている数少ないものの一つ。この投稿を書いて以来、私はテストの世界に没頭しています(私はそれが好きです)。いつそれを使うべきか(またはそうでないか)を本当に理解する前に、それをもっと理解する必要があります。ここで述べた理由の多くのために、私は常にそれを使うことを好むでしょう。しかし、最終的には私の会社/クライアントの管理下にある時間の賭けであり、多くの場合、彼らはプロジェクトの三角形の隅に焦点を当てています:en。 wikipedia.org/wiki/Project_triangle
ケンペスピサ

10

私のアドバイスは、適切に動作させたいコードのみをテストすることです。

バグを残し、将来的に問題を引き起こすコードをテストしないでください。


9
私の歯医者が言っていることを思い出す:あなたはあなたの歯のすべてをフロスする必要はなく、あなたが保持したいものだけをフロスする必要があります。
ケンペスピサ

私はそれが私にそれを考えさせたものだと告白します。;-)
ニックホッジズ

8

TDDアプローチを試すべきかどうかよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。

TDDと単体テストは同じものではありません。

コードを記述して、後で単体テストを追加できます。これはTDDではなく、多くの余分な作業です。

TDDは、赤信号のループでコーディングする方法です。緑の光。繰り返しをリファクタリングします。

これは、まだ存在しないコードのテストを作成し、テストが失敗するのを見て、コードを修正してテストが機能するようにし、コードを「正しく」することを意味します。多くの場合、これにより作業が節約されます

TDDの利点の1つは、トリビアについて考える必要が減ることです。オフバイワンエラーのようなものは消えます。APIドキュメントを検索して、返されるリストが0または1で始まるかどうかを調べる必要はありません。


オフバイワンエラーがどのように消えるかについて詳しく説明してください。ドキュメントを検索するよりも、テストによって配列のインデックスがゼロベースであるか1ベースであるかについて、より迅速に答えを得ることができると言っていますか?私にはありそうにないようです-私はGoogleでかなり速いです:)
ケンペスピサ

1
実際、TDDを記述することは、APIを探索するための優れた方法です(機能を文書化するためのレガシーコードベースを含む)。
フランクシェラー

また、そのAPIが変更された場合にも非常に便利です。突然、いくつかのテストが失敗します:
bitsoflogic

@Ken Pespisa、それは間違いなく速いです-あなたがそれが0または1だと思うかどうかに基づいてコードを書き、それを実行し、必要に応じて修正してください。ほとんどの場合、あなたは正しいでしょう、そしてあなたはそれを調べることをスキップしているでしょう、あなたが間違っているなら、あなたは10秒以内に知っています。
ポール・ブッチャー

非常に興味深い利益。そんな感じです
ケンペスピサ

3

ほとんどすべてをテストするシステムで作業しました。テストの注目すべき実行は、PDFおよびXLS出力コードでした。

どうして?データを収集し、出力の作成に使用されるモデルを構築した部分をテストすることができました。また、モデルのどの部分がPDFファイルに保存されるかを把握する部分をテストすることもできました。それは完全に主観的であるため、PDFが正常に見えるかどうかをテストすることはできませんでした。PDFのすべての部分が一般的なユーザーにとって読み取り可能であることをテストすることはできませんでした。これも主観的だからです。または、棒グラフと円グラフの選択がデータセットに対して正しい場合。

出力が主観的である場合、努力する価値があることを実行できるユニットテストはほとんどありません。


実際、この種のテストはおそらく「統合テスト」です。そして、はい、統合テストは単体テストよりもはるかに困難です。1つの理由は、「正しい」ルールのルールが非常に複雑で、主観的でさえあることです。
sleske

2

多くの場合、「手動での書き込みテスト」は、いくつかのテストを書くよりも時間がかかりません。これらのテストをいつでも再実行できるため、時間を節約できます。

あなたのテスト(コードカバレッジと混同すべきではない)といくつかのまともな機能カバレッジを持っている場合、そしてあなたは10個の機能を持っているとしましょう-ボタンをクリックすると、あなたは、およそ10持っていることを意味:考えあんた再やってテストを...座ってコーヒーを飲みながら。

あなたもしていない持って minutaeをテストします。細かい点まで踏み込みたくない場合は、機能をカバーする統合テストを作成できます... IMO、一部の単体テストでは、コードではなく言語とプラットフォームのテストがきめ細かすぎます。

TL; DRメリットがあまりにも優れているため、実際には適切ではありません。


2

私が出会った2つの非常に良い答えはここにあります:

  1. 単体テストと手動テストのタイミング
  2. 単体テストに関しては何をテストしないのですか?

知覚されるオーバーヘッドを回避する理由:

  • あなたの会社のための即時時間/コスト節約
  • あなたがいなくなった後でも、長期的にはトラブルシューティング/保守性/拡張の潜在的な時間/コストの節約。

あなたの仕事の質の証明としてあなたの側から素晴らしい製品を残したくないですか?利己的な言葉で言えば、あなたがするのはあなたにとって良いことではありませんか?


1
最後に良い質問です。私は自分の仕事を絶対に誇りに思っており、私のアプリケーションは非常にうまく機能します(もし私がとても大胆であれば)。しかし、あなたは正しい-彼らはいくつかのテストのサポートでさらに良くなる可能性があります。ここでのテイクアウェイは、コードカバレッジに夢中にならずに、プロジェクトで作業しなければならない時間内に、できるだけ多くの有用なテストに適合するよう試みることだと思います。
ケンペスピサ

1

長期的には時間を節約できるため、プロの開発者は単体テストを作成します。遅かれ早かれコードをテストし、ユーザーがそうしないと、後でバグを修正する必要がある場合、修正が難しくなり、ノックオン効果が増えます。

テストなしでコードを記述していて、バグがない場合は問題ありません。ただし、バグがゼロではない重要なシステムを作成できるとは思わないので、何らかの方法でテストしていると思います。

ユニットテストは、古いコードを変更またはリファクタリングする際の回帰を防ぐためにも重要です。彼らはあなたの変更が古いコードを壊していないことを証明しませんが、彼らはあなたに多くの自信を与えます(もちろん彼らが合格する限り:))

戻ってきて、既に出荷したコードのテストのバッチ全体を書くことはしませんが、次回機能を変更する必要があるときは、そのモジュールまたはクラスのテストを書くことをお勧めします。 +変更を適​​用する前。それがあなたを助けるかどうか見てください。

あなたがそれを試して、正直に言ってそれは十分に公平であると言うことができますが、アプローチを試用している間に少なくともあなたの価値があるようにするのに役立つ十分な業界証拠があると思います。


回帰を防ぎ、自信をつけることについての考えが好きです。これらがまさにテストを追加したい理由です。
ケンペスピサ

1

質問はTDDについてではなく、一般的な単体テストについてであるにもかかわらず、ほとんどの回答はpro-TDDのようです。

単体テストを行うか、単体テストを行わないかの背後には、完全に客観的なルールはありません。しかし、多くのプログラマーが単体テストを行わないと思われることが何度かあります。

  1. プライベートメソッド

OOPの哲学によっては、プライベートメソッドを作成して、パブリックメソッドから複雑なルーチンを分離する場合があります。パブリックメソッドは通常、さまざまな場所で呼び出され、頻繁に使用されることを意図しています。プライベートメソッドは、クラスまたはモジュール内の1つまたは2つのパブリックメソッドによって、非常に具体的な目的でのみ実際に呼び出されます。通常、パブリックメソッドの単体テストを作成するだけで十分ですが、マジックの一部を実現する基礎となるプライベートメソッドを作成することはできません。プライベートメソッドで何か問題が発生した場合は、パブリックメソッドの単体テストでこれらの問題を検出することができます。

  1. 既に動作していることがわかっているもの(または他の人がテストしたもの)

多くの新しいプログラマーは、最初にテストすることを学んでいるときにこれに反対し、実行されているすべての行をテストする必要があると考えています。外部ライブラリを使用しており、その機能が作成者によって十分にテストされ、文書化されている場合、通常、単体テストで特定の機能をテストすることは無意味です。たとえば、誰かがActiveRecordモデルがデータベースへの「before_save」コールバックで属性の正しい値を保持することを確認するテストを書くかもしれません。おそらくコールバックが呼び出しているメソッドですが、コールバックの動作自体ではありません。インポートされたライブラリの根本的な問題は、単体テストではなく、受け入れテストを通じて明らかにする必要があります。

これらの両方は、TDDを行っているかどうかに関係なく適用できます。


0

ケンと私とそこにいる他の多くの開発者は、私たちのキャリアを通じて何度もあなたと同じ結論に達しました。

他の多くの人がそうであるように、あなたが見つけるだろうと思う真実は、アプリケーションのテストを書く最初の投資は気が遠くなるように見えるかもしれませんが、うまく書いてコードの正しい部分をターゲットにすれば、本当に節約できます時間の。

私の大きな問題は、利用可能なテストフレームワークにありました。それらが私が探しているものであると本当に感じたことがなかったので、私は自分自身の非常にシンプルなソリューションを展開しました。回帰テストの「ダークサイド」に私を連れて行くのは本当に助けになりました。ここでやったことの基本的なスニペットを共有します。うまくいけば、あなたに合った解決策を見つけることができます。

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

その後の唯一のトリッキーな部分は、あなたがしているどんなプロジェクトに対しても、あなたがどの程度の粒度レベルが最高の「費用対効果」だと思うかを把握することです。

アドレス帳を作成するには、エンタープライズ検索エンジンよりもテストが少なくて済みますが、基本は実際には変わりません。

幸運を!


時間の経過とともに、どの粒度レベルが最適であるかがわかると思います。定期的にテストを作成している他の人から、彼らが賢明にアプローチし、考えられるすべての結果のテストをロボットで作成しないことを聞くのは良いことです。テストへの私の最初の紹介は、すべてのテストが必要なレベルでした。実際、TDDの概念全体がそのマントラに従っているようです。
ケンペスピサ

SubSpec(BDDに触発された)のようなフレームワークを使用するとメリットが得られると思います。そのため、コンテキストセットアップを共有しながら、Assert( "SubTest")分離を取得できます。
ヨハネスルドルフ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.