dennisrippinger / fakegen Goto Github PK

In the regular case no one would want logging information from such a test until framework, but I believe it could help to debug log null cases. This should help other developers to understand what is happening, e.g. why a nested object is null.

As 68eaba3 has shown, can some parts within the logic be dependent on executing JVM. Here the ordering of the toString() result. When the library grows, it could be interesting to see more subtle differences depending on the JVM.

Currently Fakegen has multiple signatures for different purposes. With the support for other code generators more will come. We need some kind of configuration object with defaults for immutables/Autovalue etc. Would be cool if they come with a wither notation.

By default, the TestFiller uses a different seed for each instance. Depending on the usage a possible flaky test could be not desired. Currently, it would be required to add a fixed seed directly, but a special Class with a fixed seed by default could come handy.

It may be discuraged to use Optionals as field parameters, it might be relevant to fill them in any way. For this we need to improve the Object filler interface to also provide the Method object, since we now need the generic information from the Optional. This brings also the foundation to fill iterables.

Fakegen could encounter entities with bean validation annotations present. They could present restrictions which Fakegen would currently ignore. We need an extra layer on the base values to extract bean validation constraints, depending on if the bean validation classes are present on the classpath.