The current approach to inputs works, but is a little counter-intuitive due to the combinatoric nature of the arguments. This also suffers when combined with subsections, since cohesion may drop if some subtests don't require inputs while others do.
Thus, this provides a different proposal: rather than using parameters =, provide an inputs![ ... ] macro that expands into an array that selects the correct input at runtime from the current __Context.
This could be implemented in the following way:
__Context now stores current input state (no longer just the section path).
This logic needs to be tied per-section, since sections may now start their own input fields
Have a inputs![...] macro that expands, effectively, into [...].into_iter().nth(__context.input_index())
Have each base-test context iterate through all possible inputs
Inputs now need to be determined by examining the unit test for each inputs![...] macro being used. This is applied per subtest.
This will now require a significant restructure to tests. Having subtests be able to drive parameters means that we no longer have a fixed inputs -> subtests ordering, but rather an arbitrary re-nesting of this.
The current approach to inputs works, but is a little counter-intuitive due to the combinatoric nature of the arguments. This also suffers when combined with subsections, since cohesion may drop if some subtests don't require inputs while others do.
Thus, this provides a different proposal: rather than using
parameters =, provide aninputs![ ... ]macro that expands into an array that selects the correct input at runtime from the current__Context.This could be implemented in the following way:
__Contextnow stores current input state (no longer just the section path).inputs![...]macro that expands, effectively, into[...].into_iter().nth(__context.input_index())inputs![...]macro being used. This is applied per subtest.This will now require a significant restructure to tests. Having subtests be able to drive parameters means that we no longer have a fixed inputs -> subtests ordering, but rather an arbitrary re-nesting of this.