4

VS 2010 を使用して C++ でバックギャモン ゲームを作成する際にTDDを採用しようとしています。

テスト ケースを作成するためにCxxTestをセットアップしました。

最初にテストするクラスは

class Position
{
public:
...
...
bool IsSingleMoveValid(.....)
...
...
}

関数IsSingleMoveValid()のテストを書きたいのですが、関数が正しく機能することをテストで証明する必要があると思います。残念ながら、テストするケースが非常に多く、いくつかのケースをテストしたとしても、いくつかのケースが抜け落ちる可能性があります。

何を指示してるんですか ？TDD はこれらの問題をどのように処理しますか?

4

5 に答える 5

8

いくつかのガイドライン：

  1. 通常のケースをテストします。あなたの問題では：あなたが知っている法的な動きをテストしてください。簡単な方法でテストケースをほんの一握りにするか、アプリケーションで発生する可能性のあるすべての合法的な動きを生成するループを作成して、それらすべてをテストすることができます。
  2. 境界ケースをテストします。これは実際には問題に当てはまりませんが、範囲内にある必要f(x)があることがわかっている形式の単純な数値関数をテストする場合は、通常、もテストします。（周囲にオーバーフローエッジがある内部ボード表現がある場合は、ボードゲームに関連する可能性があります）x[x_min, x_max)f(x_min-1), f(x_min), f(x_max-1), f(x_max)
  3. 既知のバグをテストします。によって認識されない法的な動きに遭遇した場合はIsSingleMoveValid()、これをテストケースとして追加してから、コードを修正します。将来のリグレッションを防ぐために、このようなテストケースを保持しておくと便利です（将来のコードの追加/変更によってこのバグが再導入される可能性があり、テストでバグが検出されます）。

テストカバレッジ（テストの対象となるコード行の割合）は、 gcovなどのツールで計算できる目標です。コードをどの程度徹底的にテストするかについては、独自の費用便益分析を行う必要があります。ただし、ゲームプログラムでの合法的な動きの検出と同じくらい重要なことについては、ここで注意することをお勧めします。

他の人は、テストをより小さなサブテストに分割することについてすでにコメントしています。その命名法は、そのような分離された関数が単体テストでテストされるのに対し、高レベルのコードでのそのような関数間のコラボレーションは統合テストでテストされるというものです。

于 2012-05-17T15:20:45.327 に答える
2

一般に、複雑なクラスを複数の単純なクラスに分割することで、それぞれがテストしやすい明確に定義されたタスクを実行します。

于 2012-05-17T15:14:02.603 に答える
2

テストを作成している場合、最も簡単な方法は、IsSingleMoveValid関数を小さな関数に分割し、個別にテストすることです。

于 2012-05-17T15:14:48.420 に答える
1

ウィキペディアでわかるように、TDD - テスト駆動開発とは、最初にテストを書くことを意味します。

あなたの場合、すべての有効な動きを確立し、それらのテスト関数を作成することを意味します。次に、すべてのテストに合格するまで、これらの破壊テストごとにコードを記述します。

...残念ながら、テストするケースが非常に多く、いくつかのケースをテストしても、いくつかのケースが逃げる可能性があります。

他の人が言ったように、関数が複雑すぎるときはリファクタリングの時です!

Kent Beck などの寄稿による Martin Fowlerの本Refactoring - Improvement the Design of Existing Codeを強くお勧めします。それは私の意見では非常に価値のある学習と参考書の両方です.

これはおそらくリファクタリングに関する最高の本であり、すべてを壊さずに関数を分割する方法を教えてくれます。また、リファクタリングは TDD にとって非常に重要な資産です。:)

于 2012-05-17T15:43:26.737 に答える
0

「テストするにはケースが多すぎる」ということはありません。一連のケースを処理するコードを記述できる場合は、それらを考慮する必要があります。それらが記述可能であり、考えられる場合、それらをテストするコードを作成することもできます。平均して、記述した (テスト可能な) コード 10 行ごとに、それに関連付けられたコードをテストするための一定の要素を追加できます。

もちろん、全体の秘訣は、テスト可能な記述に一致するコードの書き方を知ることです。

したがって、すべてのケースのテストを作成することから始める必要があります。

大きなものがある場合は、議論のために、テストする可能なケースのカウント可能なセットがあるとしましょう（つまり、すべての n および m 整数に対して add(n,m) == n+m ）が、実際のコードは本当に単純です。n+m を返します。もちろん、これは自明ですが、ポイントをお見逃しなく: ボードで可能なすべての動きをテストする必要はありません。TDD は、テストがすべてのコードをカバーすることを目的としています (つまり、テストはすべての if 分岐を実行しますコード)、必ずしもすべての可能な値または状態の組み合わせ (指数関数的に大きい) とは限りません

行カバレッジの 80 ～ 90% を持つプロジェクトは、テストがコードの 10 行ごとに 9 行を実行することを意味します。一般に、コードにバグがある場合、ほとんどの場合、特定のコード パスをたどると明らかになります。

于 2012-05-17T15:23:03.673 に答える