例ベースのテストを使用した TDD について一部の開発者が主張する 1 つの警告は、すべての有効な入力処理が欠如している可能性があることです。
これらの開発者が主張できる簡単な例を見てみましょう。
2 つの数を加算するプログラムを作成します。
開発者のボブは、最初のテストを書き始めます:
1 + 3 が与えられた場合、結果は 4です。
実装: def add(x: Int, y: Int) = 4
いいね、パス。
2 番目のテスト:
2 + 2 を指定すると、結果は 4 になります。実装は同じです: def add(x: Int, y: Int) = 4
そのため、他の開発者がやって来て、彼に次のように言いました。
「ボブは、例ベースのテストでは不十分な 2 つの例では不十分であることがわかりました。
すべての出力をテストしたわけではなく、実際の実装を見ると、結果が 4 と異なる他の入力では失敗するでしょう!
さあ、聞いてください。すべての有効な入力をカバーするために、いくつかのプロパティベースのテストを書き始めます。
それでは、加算に固有の可換性テスト、結合性などから始めましょう: 加算のプロパティ!"
でもでもでも…。 ボブのTDDの練習は本当に悪いです！確かに、彼は三角測量
を適用したかったのですが、実装を変更する必要がなかったため、すでに成功したテストを書きました!
Triangulation に導くには、失敗するテストを書く必要があります。そして三角測量は、TDD の実践の主要な鍵の 1 つです。
これにより、主なステップであるリファクタリングが可能になります。これは、2 つの異なる結果につながる 2 つのパスを管理する必要があるためです。
=> テストが具体的になる限り、コードはリファクタリングのおかげでより一般的になります。
私の質問は次のとおりです:
三角測量の優れたプラクティスで厳密な TDD を実践する場合、99% のケースで既に優れた TDD でカバーされている不変条件を主張して、プロパティベースのテストを使用することの本当の利点は何ですか?
確かに、開発者が優れた IQ を持ち、理にかなった実装を構築すると仮定すると ;)
私の例はそれらのスライドから取ったものです。