ロジックを書くよりも具体的なケースを考え出すのが難しい場合の単体テスト
私は単体テストの経験がほとんどありませんが、現在取り組んでいるプロジェクトでは単体テストをすることにしました。プロジェクトはWPF/Entity Frameworkアプリケーションです、そして私が混乱している部分はフィルタ関数です。
私たちのエンティティの世界はこのようなものです。製品、評価、そしてコレクションがあります。
評価1 - n製品
コレクションn - m評価
コレクションn - m Product
今問題となっているフィルタ関数は "コレクション内"と呼ばれ、そのロジックは次のようになります。 Collection.Active == trueであるコレクションがある場合、またはProductにCollectionがあるEvaluationがある場合は、Productを含めます。
そのため、これを単体テストするときには、考えられるさまざまなコーナーケースを見つけ出し、それらがフィルターリストに含まれるかどうかについてアサーションを作成します。アクティブなコレクションを持つ製品、アクティブなコレクションを持たないがコレクションを持つ評価を持つ製品など。
問題は、これらのコーナーケースを解決することは単純なlinq-to-entityクエリを書くことよりもはるかに難しい仕事であり、そしてテストでエラーをする可能性はフィルタの実装でエラーをすることよりはるかに高いようです。 。
そのような状況にどう対処しますか。特に簡単な方法でロジックを記述できるツールがある場合は、それほど珍しいことではありません。ここで単体テストの恩恵を受けることは可能ですか？どうやって？
一般的な知見は、テストが失敗したとき、テストされたコードは失敗しなければならないということです。しかし、これはテストが正しいことを一目で確認できる場合にのみ機能します。
実際には、テストが失敗すると、テストケースとテスト対象コードの間に矛盾があることがわかります。この矛盾は、単純なエラー（テストケースまたはテスト中のコードのいずれか）、または要件の誤解によって引き起こされます。
テストが失敗したら、矛盾の原因を突き止めてから、テストケースまたはテスト対象のコード（またはまれに両方）を修正する必要があります。
この機能のためのテストを書くのは難しいですが、テストを書くことは要件のあいまいさを明らかにする可能性があり、テストを（繰り返し）実行することは機能を壊さないという自信を与えるので、私はとにかくやることをお勧めします。
単体テストのテスト駆動開発方法を使用しているのであれば、私はあなたが単体テストの純粋主義者方法を使用することをお勧めします。
非常に単純なコードのテストをスキップしたくても、そうしないでください。
- 単体テストを書くことは、ソースコードではなくテストケースに真実の根拠を入れます（ロジックが単純であってもテストが魔法のように失敗した場合、それはテストのロジックを原因とするコードベースに惑わされますテストに失敗した場合、真実の原因がコードにあるかどうかを想像してみてください。その場合、一部の人々は、コードの実装が間違っていると考える代わりにテストが正しく書かれていないと仮定します。
- 保険単体テストを使用すると、開発段階の早い段階でバグを発見することができるので、できるだけ頻繁に使用してください。これは、あなたのコードベースの100％テストカバレッジを目指すことをお勧めします。これは、あなたのリファクタが無邪気に見える条件付きステートメントを壊さないようにするためにコードベース全体をテストする手間を省くからです。ブルームーンに一度だけ使用する方法です。
Note: Also, If you're having a bit of trouble with writing plain old unit tests, I'd suggest you take a look at cucumber and its ilk. BDD lets you write test cases more naturally so it might be easier for you in some cases.
Note 2: As @gbjbaanb, said in the comments below, even with 100% LOC test coverage, it is still no substitute of manual testing and QA. Though writing automated tests like these do help reduce the burden on the tester.
とにかくテストを書いてください。テストが必要なソフトウェア契約の一部である場合、その機能がどれほど単純であるかは無関係です。重要なのは、2次表記で厳密にテストするプロセスです。ターゲットコードとコードの他のクライアントとを組み合わせて、テストは正当性を検証する3つの定足数を構成します。あなたは一度バグを書くかもしれませんが、ロジックを誤解したり仕様が間違っていなかったりしない限り、あなたはそれを二度することはあまりありません。
あなたのユニットテスト：
- 開発した契約を検証する
- 思考プロセスを検証します。 （ゴム製のアヒルのデバッグのことを聞きましたか？）
- ドキュメントになる
- 誤って壊されないようにAPIを保護します。コードが壊れた場合、テストは大声で叫ぶ。次の立方体の新しい開発者は、彼の「修正」がテストを中断するまで、奇妙に見えるアルゴリズムはバグまたは無用なコードだと思うかもしれません。
- あなたが疲れているときあなたの世話をして、何か愚かなことをチェックインするのを防ぎます。我々は皆、時々それをします。あなたのチームメイトよりもテストのほうが賢明です。 :)
テストはあなたのソフトウェアが計画通りに実行されることを証明する唯一の方法です。長い改訂サイクルの後に単体テストが100％合格するのを見ることについて非常に慰めと満足のいくものがあると私に信じてください。
後で離れると、機能を変更または追加する必要があるときにドキュメントに記載されていないコードを壊そうとしているかどうかを知るために、他の開発者がテストから利益を得ることができます。
私が見つけた戦略の1つは、特にコードが開発された後（潜在的にかなり後に）テストが追加される場合、最初に "コンポーネント"または "統合"テストを書くことです。これは純粋な単体テストを避けるべきではないということではありませんが、システムの（望ましい）振る舞いをより高いレベルで/単体テストが難しいように理解している場合は、あなたが理解できるレベル
あなたの場合は、例えば、評価のコレクションや製品のコレクションを構築し、何らかのフィルタリング、ふるい分け、ソートなど、それらに共通の方法や操作を試してみてください。
はい、これは複数のクラスやモジュールを含み、純粋な単体テストにはなりません。そしてはい、あなたは戻って個々のクラス/モジュール/機能レベルでテストを締めくくるためにユニットテストを追加するべきです。しかし、あなたが理解しているレベルから始めることで、あなたはテストを始めることができ、あなたがさらに発見し、推論し、そして最終的にもっと多くのアトミックユニットのための直接のユニットテストを加えるのを助けるでしょう。
