データドリブン テストは、テストの入力値と出力値がコードから分離されるテスト手法です。 通常、この形式は、小規模な投資を行い、テスト コードを少し汎用的なものにすることによって、多数のテスト ケースが、関係するデータを識別するだけで記述できることを意味します。
データ ドリブン テストは、動作を定義する一連の入力値で動作する領域をテストする場合に適しています。たとえば、API をテストする場合、入力パラメーターと出力パラメーターをデータソースとして定義でき、テスト コードはデータを使用し、API 呼び出しを行い、結果を検証します。
TAEF でのデータ ドリブン テストのサポート
TAEF には、データドリブン テストを作成するためのさまざまなオプションが用意されています。 テスト シナリオに最も適したものを選択できるように、これらのオプションを理解しましょう。
テーブル ベースのデータドリブン テスト ソリューションを使用すると、パラメーターの種類を定義するだけでなく、データ パラメーターのバリエーションをきめ細かく制御できます。 この場合のデータソースは、XML ファイルで定義されたテーブルです。 パラメーター型 (int、unsigned int、size_t、bool、double、DWORD、__int64など、および同種配列のバリアント) を指定するか、型の既定値を WEX::Common::String (ネイティブ) または文字列 (マネージド) にすることができます。 テーブル内の各行は、パラメーター値のバリエーションのセットです。 テスト メソッドは、テーブル内のすべての行に対して再度呼び出されます。 テーブル ベースのデータ ドリブン テスト用の XML DataSource のスニペットを次に示します。
1 <?xml version="1.0"?>
2 <Data>
3 <Table Id ="Table1">
4 <ParameterTypes>
5 <ParameterType Name="Size">Int32</ParameterType>
6 <ParameterType Name="Color">String</ParameterType>
7 </ParameterTypes>
8 <Row>
9 <Parameter Name="Size">12</Parameter>
10 <Parameter Name="Color">Blue</Parameter>
11 </Row>
12 <Row>
13 <Parameter Name="Size">4</Parameter>
14 <Parameter Name="Color">White</Parameter>
15 </Row>
16 <Row>
17 <Parameter Name="Size">9</Parameter>
18 <Parameter Name="Color">Black</Parameter>
19 </Row>
20 </Table>
21 </Data>
詳細については、テーブル ベースのデータ ドリブン テストを参照してください。
軽量のデータドリブン テスト サポートでは、テーブル ベースのデータドリブン テスト ソリューションが提供する完全な忠実性は提供されません。 明確にするために、軽量のデータドリブン テストでは、テーブル ベースのデータドリブン テスト ソリューションでサポートされているさまざまな型に対して、データ パラメーターが WEX::Common::String(ネイティブ) または String(マネージド) に制限されます。 ただし、テスト メソッドをデータ ドリブンにするための低コストで迅速なデータバリエーション (たとえば、1 つまたは 2 つのパラメーター) を探している場合、データソースとしてXMLファイルを追加するのは、手間に見合わないように見え、軽量のデータドリブン テストがまさに探しているものであるかもしれません。 この優れた例は、OpenThemeData(...) という API の単体テストを記述し、"Button"、"Listbox"、"ScrollBar" に対して API を検証する開発者です。 このために XML DataSource ファイルを作成するのは負担が大きすぎる可能性がありますが、軽量のデータ ドリブン テストのサポートでは、ソース コード自体で効率的に行うことができます。 複数のパラメーターが指定されている場合、TAEF はバックグラウンドでパラメーターの n 方向の組み合わせ拡張を生成し、各組み合わせに対してテスト メソッドが呼び出されます。 続きを読む: 軽量のデータ ドリブン テスト。
軽量のデータドリブン テストで提供される n 方向の組み合わせ拡張は、コストがかかり、テスト シナリオがより複雑になるにつれて、リターンが減少する可能性があります。 このような複雑なテスト シナリオでは、PICT ベースのデータ ドリブン テスト ソリューションによって提供される Pairwise Independent Combinatorial Testing (PICT) が求めているソリューションである可能性があります。 PICT は、パラメーターの結果のコンパクトなセットを生成して、パラメーターに対する包括的なカバレッジを取得することで、多くの価値を提供します。 PICT の詳細と、PICT ベースのデータドリブン テスト ソリューションでこのソリューションを使用する方法の詳細については、リンクを参照してください。
WMI ベースのデータドリブン テスト サポートを使用して、テストに前提条件を追加したり、テスト マシンで使用可能なリソースに基づいて情報 (データ) を取得したりすることもできます。 例えば、マシンがドメインに加わっている場合にのみテストを実行したい場合で、テストを実行する際にドメイン名情報も必要な場合です。 この場合、データソースは WQL クエリです。 テスト シナリオで WMI ベースのデータドリブン テストを利用する方法について説明します。
上記のすべてのオプションを念頭に置くと、上記のオプションの組み合わせが適しているように見える設計を思い付くかもしれません。 たとえば、テスト マシンに接続されているすべてのプリンターに関する情報を取得するために、WMI クエリを使用したいけれども、テーブル ベースのデータドリブン テストコンストラクトを使用して事前に定義できる別のパラメーターセットがあるかもしれません。 複数のデータソース仕様は、テストのデータを 2 つの個別のテーブルから取得する場合にも便利です。各テーブルを他のテスト間で再利用できるからです。 テストに複数のデータソースを指定する方法と、その間に適用される制約の詳細を読む: 複数のデータソースを指定する