Providing DefaultObjects

[almondtools]

The generated tests often contain generic object constructors. Yet such a "constructor" tries following strategies, recovering on exceptions:

• call the standard constructor (no arguments)
• call the non-standard constructors with default values (0, false, null)
• call the non-standard constructors with objects derived from the state of the serialized object

In some cases the objects given to the contructor are not reflected in the state of the object. This may lead to a scenario where no strategy of the above matches, and the tests will fail.

So the test instrumentor should be enabled to propose construction strategies to the tests - or testrecorder could be extended by more sophisticated strategies based on all available classes in the classpath.

Provide Factory Methods One very promising idea is to use factory methods for such more complex constructors:

• these could be scanned from the classpath (identified heuristically or by annotation)
• or configured in configuration classes

Annotated classes with hints Another approach could be to identify the critical classes and to give hints how to construct then into class annotations. Probably this approach will also rely on a configuration class.

Companion classes A user might write hints how to construct an object of a certain type into a class that is similarly named. A class GodClass would have a companion class GodClassHints with a static factory method for creation and possibly other hints.

[almondtools]

We found a solution using the serializer constructor. So this issue is obsolete.

Yet object construction problems could be easily solved by simply adding a standard constructor (it may be private) to the analyzed code. Yet it is a modification of the code to analyze, but it may be protected from reuse and does not break the api.