4

Linq2Sql がとても好きなので、Linq to Sql をデータレイヤーとして使用して単純な Web アプリを作成しています。私は最近、DDD と TDD について少し読んでいて、試してみたいと思っていました。

何よりもまず、Linq2Sql と DDD がうまく機能していないことに気が付きました。私のもう 1 つの問題は、テストを見つけることです。実際、良いテストを定義するのは非常に難しいと感じているので、質問したいと思いました。

4

6 に答える 6

5

まあ、TDD の標準的な解釈によれば、テストが開発を推進するということです。つまり、本質的に、テストから始めます。テストは失敗し、そのテストに合格するまでコードを記述します。ですから、それはあなたの要求によって動かされますが、あなたはそれらを集めようとします. アプリ/機能が何をする必要があるかを決定し、テストを記述してから、合格するまでコーディングします。もちろん、他にも多くの手法がありますが、これは TDD の世界で一般的に考えられていることを簡単に説明したものです。

于 2009-01-07T00:11:19.170 に答える
5

テスト ケースの発見は、科学というより芸術です。ただし、簡単なガイドラインは次のとおりです。

  • もろい/弱い/壊れやすいとわかっているコード
  • ユーザー シナリオ (ユーザーが何をするか) に従って、それがコードにどのように影響するかを確認します (多くの場合、これはデバッグを意味し、別の場合はプロファイリングを意味し、別の場合は単純にシナリオについて考えることを意味します) - コード内のどの点に触れてもかまいません。ユーザーによって、それらはテストを書くための最優先事項です。
  • 独自の開発中に実行したテストにより、発見したバグが発生しました。同じ動作でコードが再び後退するのを避けるためにテストを記述してください。

テスト ケースの書き方に関する書籍は数冊出回っていますが、ドキュメント化されたテスト ケースを必要とする大規模な組織で作業している場合を除き、コード内の好ましくない部分 (つまり、 「純粋」ではありません）、それらのモジュールを完全にテストできることを確認してください。

于 2009-01-07T00:20:16.873 に答える
1

テストの実際の目標、つまりバグを見つけることに心を向けてください。

プログラムが失敗する原因を創造的に想像してください。

テストはバグを見つける必要がありますが、プログラムが正常であることを確認する必要はありません。

于 2009-01-08T11:12:54.433 に答える
0

これは便利なテクニックだと思います：

コントラクトとブールクエリを使用して自動テスト生成の品質を向上させる

参照: Lisa (Ling) Liu、Bertrand Meyer、Bernd Schoeller、Tap : Tests And Proofsの議事録、ETH Zurich、2007 年 2 月 5-6 日、eds. Yuri Gurevich と Bertrand Meyer、コンピュータ サイエンスの講義ノート、Springer-Verlag、2007 年。

于 2009-01-08T11:16:07.220 に答える
0

私は定期的にサードパーティ API のテストを書いています。そうすれば、API が更新されたときに、壊れるかどうかがわかります。

于 2009-01-07T00:54:32.390 に答える