When writing java tests for an application, be they unit tests or testing a broader scope, the java community tends to model fixtures in terms of object factories that produce fixtures of a defined state.
eg:
public class TestFixtureGeneratorA{
static public A modelAState1(){
A a = new A();
a.setFoo(1);
a.setBar("bar");
}
static public A modelAState2(){
A a = new A();
a.setFoo(2);
a.setBar("baz");
}
}
Whereas, coming from a BDD or Agile methodologies perspective, it would seem more sensible to encode fixtures in terms of their applied scenario and feature or test.
eg:
//file: src/test/resources/fixtures/scenarioA/interaction1/A.json
{
foo: 1,
bar: "bar"
}
//file: src/test/resources/fixtures/scenarioA/interaction2/A.json
{
foo: 2,
bar: "baz"
}
//file: src/test/resources/fixtures/scenarioA/interaction2/ids.json
[42, 101, 1337]
And then have your test execute in the scope provided by scenarioA interactionX.
I have seen this kind of thing in agile driven teams that model from business requirement to code (ie: they maintain a full BDD stack), none of them java shops) and once in a relatively big industry application. But trying to look up literature on the practice was fruitless. There does seem to be one implementation at Corballis' GitHub repository providing annotation based test infrastructure, similar to the one described above but other than that the Web seems devoid of work on this subject.
Given the succinctness of JSON and the probably better formalization/integration aspects of the JSON based fixture mechanic, how come it didn't get discussed until now? Are there any apparent drawbacks I'm missing?
Note: This is taken from personal experience in a multitude of projects, mostly in Java, highly diversified (some where millions SLOC, others have insane performance requirements, etc).