はじめに
Table Driven Tests は主に Go lang で推奨されるテスト手法です。 入力と期待される結果を含む完全なテストケースをテーブルとして定義し、テスト対象に対してテストケースをイテレーションしてテストを行います。 つまり、テストスイートを 1 回だけ記述し、テストデータを渡すことができます。 テストを作成するときにコピーアンドペーストが多い場合、テストケースをテーブルにリファクタリングできる可能性が高いです。
ちなみに Go lang の公式では次のように述べられています。
Writing good tests is not trivial, but in many situations a lot of ground can be covered with table-driven tests
jest でも Table Driven Test がサポートされているので、その方法を共有したいと思います。
テストケースの書き方
jest では 2 つの書き方でテストケースを表現できます。テスト対象として条件分岐があるような次のケースを考えます。
index.html 以外の *.html を */index.html に変換する関数
この関数自体は、Server Side Generation の実装 でファイルを生成する際に、ディレクトリを掘ってほしいときに使いました。レアケースですかね笑
テーブルの配列でテストする
1 つ目の書き方は、テーブルを配列として定義して渡す方法です。 次のように書きます。
Alias があるのでいくつかのオブジェクトが each
メソッドを持っています。
具体的なテストケースは次のようになります。
テストケースを2次元配列で記述します。配列内の要素の順番はそのままに fn
の引数として渡されます。
また、 name
にはテストスイートのタイトルを指定します。 printf
の書式に従うパラメータを注入することで、ユニークなテストタイトルを生成できます。
詳細はこちらを確認してください。
これも配列の要素順にパラメータが渡されます。
ちなみに 1 次元の配列を渡した場合には、内部的には [1, 2, 3]
-> [[1],[2],[3]]
のように変換されます。
また、fn
に渡されるパラメーターは TypeScript の場合、型推論されます。
上の例では table
が string[][]
型なので、 fn
の引数は ...args: string[]
と推論されます。
タプルとして推論させる場合は as const
を table
につけるとうまく推論されます。
他にも each
メソッドはジェネリックス型を受け入れるので、次のように型を指定できます。
このテストを実行すると次の出力になりました。
パラメーターがテストタイトルに埋め込まれてます。テストスイートを最小限に、様々なパラメーターのテストができました。
タグ付きテンプレートリテラルでテストする
タグ付きテンプレートリテラルでテーブルを表現することもできます。
インターフェイスは次のようになります。
実際に上の例と同じテストを書くと、次のようになります。
table
の 1 行目は変数名を指定します。後続の行は ${value}
構文でテストケースを記述します。 string
型でも ${}
で囲わなければなりません。
fn
の引数にはオブジェクトの形式で渡されるので、分割代入で受け取るといいと思います。
name
のテストタイトルにパラメーターを使う場合は $name
形式で変数にアクセスできます。
この記法だと、テーブルの形でテストケースを記述できる点が利点です。
しかし、 string
の多いテストケースの場合は ${}
と クオートであまり見やすくはありませんね。
また、この記法では fn
の引数の型推論が any
型になってしまいます。
タグ付きテンプレートリテラルなので、ジェネリクスを受け入れられないため、これは仕方がありません。
どうしても型をつけたい場合は、fn
関数に型を定義します。
結果はどちらも同じになるので、テストケースや好みで記法を使い分けるといいと思います。
Edit this page on GitHub