2

直感的でない計算を実行するいくつかのパラメーターを持つ短い（Java）メソッドがあります。コードカバレッジを達成するためにこのメソッドの単体テストを作成するのは簡単ですが、テストはメソッドの微妙な点をカバーしていません。パラメータ用に定義したパーティションに基づいて、このメソッドのすべてのペア（すべてのタプル）のテストを実行できるテストフレームワークまたはその他のツールを探しています。

たとえば、次の方法があるとします。

int foo(int begin, int end, int first, int last) {
    ...
}

私はすでにいくつかの制約を知っていますが、それは外部から強制される可能性があります。

begin <= end
first <= last

私自身のパラメータの知識に基づいて、明示的な同値関係を定義したいと思います。例えば：

begin == MIN
begin > MIN && begin < 0
begin == 0
begin == 1
begin > 1 && begin < MAX
begin == MAX

また、複数のパラメーターを含む同値関係を定義したいと思います。例えば：

begin + 1 < end
begin + 1 == end
begin == end

テストする組み合わせは、制約が満たされるように、各同値関係begin == 0から（たとえば、最初の関係と2番目の関係から）同値類を選択することです。begin + 1 < end[ちなみに、充足可能性はNP完全であることに気づきました。比較的少数の制約のセットを構成する組み合わせを考えると、私はそれを喜んで受け入れます。]いくつかのパラメーターを使用すると、組み合わせの数が扱いにくくなります。組み合わせごとにテストを手動で作成し、結果として得られる一連の制約を満たす引数を見つけるのは面倒で、エラーが発生しやすくなります。

私は、各組み合わせを自動的にテストできるテストフレームワーク、または論理的に一貫した組み合わせごとにテストを生成できるテストジェネレーター（本当にあなたが挿入する不変のチェック）を探しています。これは、実際の実装からテストケースを生成するCodeProのようなテスト生成ツールとは異なります。事実上、実装ではなく、メソッドのインターフェースのテストを生成したいと思います。これにより、メソッドが実装される前にテストを作成できるようになるだけでなく（TDD）、後で変更した後でもメソッドが包括的にテストされるようになります。

そのようなツールは存在しますか、それとも何かをまとめることができますか？または、おそらく私はこれに間違った方法でアプローチしています、そしてあなたは別の提案があります...

4

5 に答える 5

2

テストフレームワークの外部でツールを使用できますか？もしそうなら、私はジェームズ・バッハのAllPairsを使用して良い結果を出しました。Hexawiseもあります。

気づかなかった場合は、http：//pairwise.orgは、ペアワイズおよび組み合わせのテストとツールについて読むのに最適な場所です。

于 2012-05-30T11:14:51.100 に答える
2

最も内側のループの反復ごとにテストメソッドが呼び出される単純なネストされたループは、法案に適合しませんか（または少なくとも大部分は法案に適合します）？

何かのようなもの：

int[] ends = new int[] {-50, -10, -1, 0, 1, 50, MIN, MAX};
for (int end : ends) {
    int[] begins = new int[] {end - 10, end - 1, end, MIN, MAX};
    for (int begin : begins) {
        if (begin <= end && begin >= MIN && begin <= MAX) {
             testFoo(begin, end);
        }
    }
}
于 2012-05-29T10:33:24.200 に答える
2

これに関するいくつかのアイデアについては、DavidSaffの理論テストに関する作業を参照してください。

于 2012-05-29T13:45:43.147 に答える
1

JUnitフレームワークの下で組み合わせテストを実行するライブラリにまだ興味がある場合。私は最近、まさにそれを実行するライブラリ「JCUnit」を実装しました。

JUnitの下でテストケースを生成し、それらを使用してテストメソッドを実行します。

http://dakusui.g​​ithub.io/jcunit/

于 2014-08-30T14:27:42.660 に答える
0

アルゴリズムをTDDした場合は、すでに十分なテストカバレッジがある可能性があります。その後誰かがやって来てアルゴリズムを変更した場合、元のテストの少なくとも1つが壊れているのがわかるはずです。テストするエッジ条件がいくつかある場合は、いくつか書くことができますが、これらのエッジを追加すると赤くなるほど面白くない場合は、既存のテストを維持して複製するのに十分面白くない可能性があります。 。冗長なテストはあまり価値がなく、私はそれらを削除する傾向があります。

于 2012-05-29T11:41:30.273 に答える