Cucumber(-JVM)、Junit、Java 8 を使用して、XML ファイル (最大数百のフィールドを持つ) を受け入れるアプリケーションの受け入れテスト フレームワークを作成しています。 Builder インターフェース (数十のコンストラクターを持つことを避け、ある種の宣言型 API を持つことを避けるため)、つまり:
new Form.Builder
.setThisField(withThis)
.setThatField(withThat)
.build();
テストで有効な XML ファイルを動的に生成したいので、このライブラリを作成しました。キュウリのシナリオを英語のように読みたいので、次のように書く代わりにデータ テーブルを使用することにしました。
Given I have a form with x field
and with y field
and with z field
and ...
50 の異なる 'and' 行。したがって、それらは次のようになります。
Given that I have Form B101 with the following fields:
| X Field | X Value |
| Y Field | Y Value |
| Z Field | Z Value |
問題：
キュウリ データ テーブル (HashMap に変換される) のキーをビルダー パターンのメソッド名にマップする必要があります。最初は、ラムダとメソッド参照を使用するとこれを達成できるのではないかと考えましたが、まだ方法を見つけていません。
それで、私の次の考えは反省でした。Cucumber Data テーブルのキーからメソッド名へのマッピングを、次のようなプロパティ ファイルに保存することにしました。
//mapping.properties
X\ Field = setXField
// the \ after X is to escape the space
ただし、問題が発生しました。キュウリ データ テーブルのフィールドの一部が、XML データ バインディング ライブラリの深くネストされたフィールド (XML スキーマによる) にマップされます。たとえば、次のようになります。
「X フィールド」は A フィールド内にネストされています。したがって、私のテストメソッドでは、次のことを行う必要があります。
AField aField = new AField(new XField());
しかし、Java でのリフレクションでは、パラメーターのデータ型を事前に知っておく必要があります (またはそう思います)。たとえば、メソッドに関連付けられているパラメーターの型を知りたい場合は、次のようにします。
Class[] paramString = new Class[1];
paramString[0] = AField.class;
// So I need to know before the fact that methodName (below) has a parameter
// of type AField in order to .... get the parameter types of methodName.
// this is legal because a method with methodName exists and it takes
// one parameter with type AField.
Class[] parameterTypes =
formB.getClass().getMethod(methodName, paramString).getParameterTypes();
// this is not legal. no method named methodName which doesn't
// take parameters exists
Class[] parameterTypes =
formB.getClass().getMethod(methodName).getParameterTypes();
これに対する回避策を見つけることができると確信していますが、最終的には「ハック」パスをたどっているようです。この問題にアプローチするより良い方法はありますか? それとも私は「正しい」道を進んでいますか？