unit-testing - 短期/長期シナリオでの単体テストと探索的テスト

Question

単体テストまたは探索的テストという製品に、より多くの価値をもたらすものは何だと思いますか？

どちらのテストも一般的な目的が異なることを理解していますが、どのテストを優先しますか。つまり、最初に何をし、次に何をしますか、ユニットまたは探索的ですか。

また、短期的にはどちらがより多くの利益を支払いますか？そして長期的には？

最後に、2つのうちの1つだけの時間がある場合、あなたの答えは変わりますか？

Answer 1

私の意見では、両方が重要です。私はTDD方法論に従っているので、単体テストは私のコードの実行可能な仕様を形成します。ユニットテストを最初に実行する必要がありますが、その過程で、合格したユニットテストを作成するために何らかの形式の探索的テストを実行していることがよくあります。さらに、何らかの形の調査なしでは完全に開発できないもの（たとえば、インターフェース設計）があります。はい、多くの場合、インターフェース要素が期待どおりに動作することを確認するための単体テストを開発できますが、相互作用する方法を決定する前に、さまざまな要素がどのように相互作用するかを確認する必要があります。さまざまなシナリオを調査し、フィードバックに基づいてテストスクリプトを調整することは、設計の重要な部分です。

非インターフェース作業の場合、最初に単体テストを実行し、必要に応じて探索的テストを実行します。インターフェースの作業については、プロトタイプを作成して調査し、ユニット（スクリプト）テストを開発します。これは、各スペースのテストツールの機能に一部起因していますが、実行されている作業の種類にも関係しています。

メリットについては、さまざまなメリットがあるため、比較するのは難しいです。どちらのタイプのテストでも欠陥を見つけて排除できますが、単体テスト（TDDを使用）は、アプリケーションの設計と構造もガイドおよび改善します。デザインを改善することで、保守性も向上します。私の意見では、探索的テストは主にアプリケーションの使いやすさを向上させますが、設計上の決定が実際に期待どおりに機能するかどうかを評価し、設計が進化するにつれて検証するために使用できます。

私の意見では、単体テストは、他のすべてのテストが変化を生み出すために機能できるセーフティネットを提供するという点で、より基本的なものです。その意味で、それらはより重要ですが、現実的な環境ではどちらもなしではできません。また、ユニットテストや統合テストと同じように、これらは2種類のテストだけではなく、実際に直接比較することもできません。デバッガーを使用したい場合は、探索である単体テストを実行できます。

自動化されたスクリプト化されたテストを実行する時間がないシナリオを想像できますが、少なくとも私にとっては、これらはエッジケースです。手動の探索的テストを使用しても、ある程度の単体テストを実行しないシナリオは想像できません。実際、ある程度の単体テストが不要になる前に、アプリケーションは非常に単純である必要があります。