Closed severn-everett closed 1 year ago
Hi @severn-everett! May I aks you why you need custom parameter generators? We are now designing a new, better API, and this information would help a lot.
Enum classes, basically. I wanted to modify the MultiMapTest example to work with tests that would pass in an enum value for the key instead of an integer. I could do that with an IntGen and obtain the randomized enum value via AnEnum.values()[i]
, but 1) I wouldn't be able to configure the IntGen range in a secure way - the range that gets passed in is a string in the annotation, and that requires a compile-time constant, so passing in AnEnum.values().size
won't work - and 2) it would pollute the testing functions with test setup code.
A side-note: does this mean that the generator classes are going to be refactored? I was thinking of converting them to Kotlin to improve dogfooding for the project, but if there's a better place to concentrate my efforts on, please let me know.
I've created an issue to support enum
classes properly; please see #186.
does this mean that the generator classes are going to be refactored?
We are working on a new API. We are still designing the part related to parameter generation, but the current API will become deprecated anyway.
There is an implicit contract for classes that implement
ParameterGenerator
: that they contain a constructor that accepts the argumentsRandomProvider
andString
so that an instance of the class can be created inCTestStructure
. If a class does not implement this constructor, a test that includes the class will fail with the output:As such, either the interface
ParameterGenerator
should be converted into an abstract class with the required constructor so that the developer can be aware of the requirements for their custom generator classes or the interface should be modified so that it requires the expected fields.