データの配置が面倒すぎる場合のテスト方法

私はパーサーを書いており、その一部として、Expander単一の複雑なステートメントを複数の単純なステートメントに「拡張」するクラスがあります。たとえば、これはこれを展開します：

x = 2 + 3 * a

に：

tmp1 = 3 * a
x = 2 + tmp1

今、私はこのクラスをテストする方法、具体的にはテストを配置する方法を考えています。入力構文ツリーを手動で作成できます。

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

または、文字列として記述して解析することもできます。

var input = new Parser().ParseStatement("x = 2 + 3 * a");

2番目のオプションは、はるかに単純で、短く、読みやすいです。ただし、に依存性が導入さParserれるため、のバグParserがこのテストに失敗する可能性があります。だから、テストはのユニットテストされて停止だろうExpander、と私は、技術的の統合テストとなり推測ParserとExpander。

私の質問は、このExpanderクラスをテストするために、この種の統合テストにほとんど（または完全に）依存しても大丈夫ですか？

簡単にできれば、はるかに複雑で、興味深く、有用な動作の、より多くのテストを書くことに気付くでしょう。したがって、関連するオプション

var input = new Parser().ParseStatement("x = 2 + 3 * a");

かなり有効です。別のコンポーネントに依存します。しかし、すべてが依存する数十の他のコンポーネントの。人生の1インチ以内に何かをモックする場合、おそらく多くのモック機能とテストフィクスチャに依存しています。

開発者は、モジュール、統合、ストレス、または他の種類のテストなしで、単体テストの純度に過度に焦点を当てたり、単体テストと単体テストのみを開発したりすることがあります。これらのフォームはすべて有効で有用であり、Q / Aや運用担当者だけでなく、開発者のすべてが適切な責任を負っています。

私が使用したアプローチの1つは、これらの高レベルの実行から開始し、それらから生成されたデータを使用して、テストの長形式で最小公分母の式を構築することです。たとえば、input上記で生成されたデータ構造をダンプする場合、次のものを簡単に構築できます。

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

最も低いレベルでテストする一種のテスト。そうすれば、素敵なミックスを手に入れることができます。ごく少数の非常に基本的なプリミティブテスト（純粋な単体テスト）ですが、そのプリミティブレベルでテストを書くのに1週間も費やしていません。これによりParser、ヘルパーを使用してより多くの、やや少ないアトミックテストを作成するために必要な時間リソースが得られます。最終結果：より多くのテスト、より多くのカバレッジ、より多くのコーナーと他の興味深いケース、より良いコードとより高い品質保証。

もちろん大丈夫です！

完全なコードパスを実行する機能/統合テストが常に必要です。この場合の完全なコードパスとは、生成されたコードの評価を含めることを意味します。それはあなたが解析がいることをテストであるx = 2 + 3 * a場合と、実行するコードを生成a = 5意志セットxに17実行している場合は、とのa = -2意志セットxに-4。

これより下では、実際にコードのデバッグに役立つ限り、より小さなビットの単体テストを行う必要があります。テストがきめ細かくなればなるほど、内部インターフェイスが変更されるため、コードの変更でもテストを変更する必要が生じる可能性が高くなります。このようなテストには長期的な価値がほとんどなく、メンテナンス作業が追加されます。そのため、収益が減少するポイントがあり、その前に停止する必要があります。

単体テストを使用すると、破損する特定の項目と、コード内のどこで破損したかを特定できます。そのため、非常に細かいテストに適しています。優れた単体テストは、デバッグ時間の短縮に役立ちます。

しかし、私の経験からすると、単体テストで適切な動作を実際に検証するのに十分なことはほとんどありません。したがって、統合テストは、操作のチェーンまたはシーケンスを検証するのにも役立ちます。統合テストは、機能テストの一部を提供します。指摘したように、統合テストは複雑であるため、コード内でテストが中断する特定の場所を見つけることは困難です。また、チェーンのどこかで障害が発生するとテストが失敗するという点で、やや脆弱です。ただし、実稼働コードには引き続きそのチェーンが存在するため、実際のチェーンをテストすることは依然として役立ちます。

理想的には両方がありますが、いずれにしても、一般的に自動テストを行う方がテストを行わないよりも優れています。

パーサーで多くのテストを行い、パーサーがテストに合格したら、それらの出力をファイルに保存してパーサーをモックし、他のコンポーネントをテストします。