TDD、良いテストを見つけるためのテクニックは何ですか?
-
03-07-2019 - |
質問
Linq2Sqlがとても好きなので、Linq to Sqlをデータレイヤーとして使用するシンプルなWebアプリを書いています。私は最近DDDとTDDについて少し読んでいて、それを試してみたいと思いました。
何よりもまず、Linq2SqlとDDDがあまりうまく機能しないことが印象的です。私の他の問題はテストを見つけることです。実際、良いテストを定義するのは非常に難しいので、良いテストケースを発見するためのあなたの最善のテクニックは何ですかと尋ねました。
解決
テストケースの発見は、科学というよりも芸術です。ただし、簡単なガイドラインは次のとおりです。
- 脆弱であることがわかっている/脆弱である/壊れそうなコード
- ユーザーシナリオ(ユーザーが行うこと)に従って、コードがコードにどのように影響するかを確認します(多くの場合、これはデバッグ、プロファイリング、およびシナリオについて考えることを意味します)-ユーザーがコードに触れると、それらはテストを書くための最優先事項です。
- 独自の開発中に、実行したテストでバグが見つかった-同じ動作でコードが再び退行しないようにテストを作成します。
テストケースの作成方法に関する書籍は複数ありますが、文書化されたテストケースを必要とする大規模な組織で作業している場合を除き、コード内の好ましくない部分をすべて考慮することをお勧めします(「純粋」ではない)、それらのモジュールを徹底的にテストできることを確認してください。
他のヒント
さて、TDDの標準的な解釈では、テストは開発をドライブするというものです。したがって、本質的にはテストから始めます。失敗し、テストに合格するまでコードを記述します。そのため、要件に左右されますが、それらを収集します。あなたはあなたのアプリ/機能が何をする必要があるかを決定し、テストを書き、それが合格するまでコーディングします。もちろん、他にも多くの手法がありますが、これはTDDの世界で一般的に考えられていることについての簡単な説明です。
考える。コードを読んでください。自分に質問:例ここでこのポインターがNULLになることはありませんか?このメソッドが初期化の前に呼び出されるとどうなりますか?
仮定しないでください" このファイルは常に存在します"など。テスト。
エッジケース、境界、負の値、オーバーフローについて考えます...
バグは多くの場合、クラスターごとにグループ化されます。見つけたら周りを見てください。他の場所でも同じ種類のバグを探してください。
テストの実際の目標であるバグの発見に心を向けます。
プログラムが失敗する原因を想像して創造力を発揮してください。
テストではバグを見つける必要があり、プログラムが正常であることを確認する必要はありません。
サードパーティAPIのテストを定期的に書いています。そうすれば、APIが更新されたときに、壊れるかどうかがわかります。
これは便利なテクニックだと思います:
コントラクトとブールクエリを使用して自動テスト生成の品質を向上させる
参考:リサ(リン)リウ、バートランドマイヤー、 Bernd Schoeller、コントラクトとブールクエリを使用して、 自動テスト生成の品質、 TAP:テストの議事録 そして、証拠、ETHチューリッヒ、2007年2月5-6日、編。ユーリ・グレヴィッチと Bertrand Meyer、コンピューターサイエンスの講義ノート、Springer- Verlag、2007年。