Support JSON as source for parameterized tests arguments

Implement an ArgumentConverter that parses JSON and an ArgumentSource that parses JSON files and passes them as arguments to a parameterized test.

This is pretty straightforward for a single file and parameter:

@ParameterizedTest
@JsonSource("customers.json")
void testCustomer(Customer customer) { /*...*/ }

It’s a little unclear how to parse files for two parameters, though. There could be one file per parameter…

@ParameterizedTest
@JsonSource({ "customers.json", "contracts.json" })
void testCustomer(Customer customer, Contract contract) { /*...*/ }

… but then customer/contract pairs would be far apart and hard to identify by looking at the files.

Alternatively, there could be a top-level container…

{
	customer: { /*...*/ }
	contract: { /*...*/ }
}

… and the parser takes them apart when resolving parameter:

@ParameterizedTest
@JsonSource({ "customers-contracrs.json" })
void testCustomer(Customer customer, Contract contract) { /*...*/ }

[nipafx]

I like your approach, @filiphr. Having a single JS object per invocation makes more sense than what I proposed above. I also like deconstruction in testCustomerFields. 👍🏾

Regarding @aepfli’s proposal for default data, I think we should not implement that in the first try but that raises the question whether we already want to prepare for such a scenario by requiring the actual data on a top-level data field. That may be needlessly cumbersome for the 9x% of cases that only use data, though. To address this, we could give @JsonSource an optional argument that specifies the attribute name that contains the value or value array, e.g:

ParameterizedTest
@JsonSource(value = "customers.json", data = "the-customers")
void testCustomer(Customer customer) { /*...*/ }

{
	"the-customers": [
		{ ... }
	]
}

It could default to a constant ROOT that specifies the data is in the document’s root.

[nipafx]

I 100% agree with your @JsonSource argument: It should accept a string (or array thereof - that looks good, too!) as value, so the attribute doesn’t need to be specified.

Regarding two-vs-three annotations, I definitely like three annotations, i.e. one per use case, better. It seems cleaner and makes those easier to use as well (because they can rely on value). First question: Do you agree?

Then of course, there’s the symmetry with JUnit Jupiter, which is definitely nice to have as it makes it easier for users to adopt these features. Weighing ease-of-learning (two annotations) against ease-of-use (three annotations), I lean towards the latter and would go with three annotations. Second question: What do you think?

If both answers are on line with mine, you can just go ahead and refactor accordingly. Otherwise let’s fight discuss.