Description
(This is primarily a note for me to look into this more shortly, since I've come up against it in #639)
@DataPoints array methods are called once in AllMembersSupplier, and the values then reused for each theory.
Single DataPoint methods are instead called once for each possible assignment (for each unique and complete set of values for the given theory method)
This means that mutable values in DataPoints return values can be changed and then easily cause interactions between tests. Single DataPoint values can't though, and indeed there's a test specifically checking this (WithDataPointMethod.mutableObjectsAreCreatedAfresh).
Meanwhile field values are always reused (since they clearly can't be regenerated).
I think (debatable) both these datapoint method evaluation mechanisms should really be made to match instead, one way or the other, either by deferring array method execution somehow (quite complicated and hard to define), or by making single DataPoint values shared, as all other DataPoint values are.
I think (very very debatable) just running each DataPoint method once at the start and reusing all the values consistently is better myself (more intuitive to use, much simpler to implement). Datapoints also arguably really shouldn't be mutable in normal usage anyway. Finally users that do desire this behaviour can instead create a ParameterSupplier to support their specific instances of this case (where values must be regenerated) fairly simply: define a ParameterSupplier that returns a PotentialAssignment subclass where getValue() generates the new value in some way, rather than just returning the same one.