0

ツリーの実装とそのノードのさまざまな「移動」アクションをテストする必要があります。私のツリーはDBに保存されます（この場合はmongoDBですが、それほど重要ではありません）。最善のアプローチは何でしょうか？JUnitを使用しています。

これまでの私の考えは次のとおりです。

  • ツリー構造を作成してDBに保存するsetUpメソッドを用意します
  • setUpメソッドに、ノードごとに次の詳細を含むツリーのメモリ内コピーを作成させます：親ID、位置、名前
  • テストしたい各テスト関数を実行します。たとえば、ノードをAからBに移動します
  • インメモリを新しいインDBバージョンと比較します。見つかった各差分を伝播する
  • 差分の変更が予想されることを主張する

インメモリコピーを作成する理由は、複雑なツリー（複数のレベルとレベルごとのノード）に対してテストするためです。それ以外の場合は、テストごとに各ノードをテストする必要があります。

これは意味がありますか？より良いアプローチ（またはより良い：私のためにそれを行うことができるライブラリ）？

ありがとう！

4

3 に答える 3

1

あなたのアプローチは良さそうですね。1 つの変更を提案します。データベースの代わりに、特定のツリーの文字列 XML 表現を生成し、特定の XML 表現からツリーを再作成する 2 つの再帰メソッドを記述します。

初期ツリーと期待されるツリーを各テスト ケースの XML 文字列として保存できます。テスト ケースのアサーションは、一連のアクションの後のツリーの文字列 XML 表現が期待される XML 文字列と等しいかどうかです。

さまざまな XML 文字列を視覚的に検査するのは簡単で、テストが失敗したときに実際の XML を確認し、それを期待される XML と視覚的に比較できるため、デバッグが容易になります。実際、テスト ケースをレコード モードで実行することもできます。この場合、レビューと承認のために結果の XML を書き出すだけです。

于 2012-07-29T15:05:25.300 に答える
0

このアプローチは非常に公平に思えます。メモリ内レプリカを使用してツリーを構築し、テスト対象のツリーとメモリ内インスタンスでノードの移動を開始し、それらが同じかどうかを確認します。

しかし、最も重要なことは、事前定義された両方のユースケースを使用することです-

  • 空の木
  • 左右の息子のみ
  • 再帰移動
  • リーフムーブ
  • ...

ランダムツリーを使用する別のテスト。

これはおそらくほとんどのケースをカバーし、その後のコードにはかなり自信を持っているはずです.

于 2012-07-29T15:04:48.623 に答える
0

理想的には、ツリーの永続性を提供するコードは、それを操作するコードから独立している必要があります。このようにして、それらを個別にテストおよび変更できます。

テスト目的で、ネストされた括弧で囲まれた文字列を取るツリー構築方法を検討できます。同じ形式に toString メソッドを追加すると、理想的なテストおよびデバッグ機能が得られます。

例えば：

Tree sut( "(root,left,(right,a,b))" );
ASSERT_EQUALS( "(root,(left,c,),(right,a,b))", sut.methodUnderTest(c).toString());

ルート、左、右などとして示したものは、実際には「{ルート、x、y、名前、値}」などの実際の構造のより複雑な表現である可能性があります。

要点は、各テストを理解するのにかかる時間を短縮し、コードをカバーするのに十分なテストを作成する時間を確保できるように、すばやく作成できて簡単に理解できるテストを作成することです。

ツリー データへの変更からテストを分離することが重要です。これを容易にするために、.toString() を使用する代わりに、あまり頻繁に変更されない .toTestString() を追加できます。そうすれば、テストを中断することなく、ツリー オブジェクトに追加して .toString() を変更できます。同様に、文字列からのツリー構築メソッドは別のクラスになる場合があります。

于 2012-07-29T15:09:29.480 に答える