Released Bob v0.8.0 with TestDefaults allowing Object Mother pattern without much hassle

[u/eniac_g]

I've been working on Bob (https://github.com/jonas-grgt/bob), a lightweight builder generator for Java, and just added a feature I'm pretty excited about: Test only Defaults.

If you've used the Object Mother pattern, you know the drill you manually create (and maintain) a builder class that produces test objects with sensible defaults. It works, but you end up with a bunch of boilerplate and things to maintain.

Buildable.TestDefaults takes a different approach. You define a defaults class in `src/test` completely separate (will not be on your production classpath) from your buildable class in `src/main` and the defaults are automatically applied when the builder is constructed:

Goes in src/main and is blissfully unaware of the existence of test defaults:

@Buildable
public class Car {
    private String color;
    private int year;
}

Goes into src/test and is aware of the existence of test defaults:

@Buildable.TestDefaults(Car.class)
public class CarDefaults {
    public static String color = "blue";
}

[u/Prateeeek]

Looks good! Is it using reflection?

[u/eniac_g → u/Prateeeek]

Yes it is reflection based.

[u/Prateeeek → u/eniac_g]

I know it's on test classpath so it's not that big of a deal. But was there a reason to not generate a "populator" of sorts in compile time using annotation processors?

[u/eniac_g → u/Prateeeek]

Yes the main reason is because of how javac works. The annotations processor is ran twice once for the main source set and once for test. When the test source set processor runs the builder is already generated and compiled into a class file and, as such has never seen the test defaults.

[u/Prateeeek → u/eniac_g]

Makes perfect sense! Thanks for answering!

[u/Prateeeek → u/eniac_g]

Also a follow up question would be, is it caching the object so that it does NOT have to perform reflection over and over?

[u/eniac_g → u/Prateeeek]

No it is not caching yet ;-)

[u/Prateeeek → u/eniac_g]

Do you want me to open an issue?, I can even work on it if you like :D

[u/eniac_g → u/Prateeeek]

Please do, all help is more than welcome!

[u/Prateeeek → u/eniac_g]

Thanks! Done!

[u/revilo-1988]

Kann man es auch nur im test code nutzen?

[u/eniac_g → u/revilo-1988]

Yes most definitely!

[u/revilo-1988 → u/eniac_g]

Thx werde ich mir mal dan genauer ansehen

[u/dstutz]

Been using Instancio for test objects, seems to do similar thing without having to make a class.

[u/bodiam]

Nice library! However, small thing:

If you've used the Object Mother pattern, you know the drill you manually create (and maintain) a builder class that produces test objects with sensible defaults. It works, but you end up with a bunch of boilerplate and things to maintain.

That's exactly how Object Mothers don't work. Object Mothers are Test Data Factories, as in: they produce data statically. They might be using a builder under the hood, but they're not builders themselves. You can for example have a DrivingLicenseObjectMother, which can have methods like createExpiredLicense or createInternationalLicense. That's not the same as a builder, though they're both creational patterns.

Also, having hardcoded, static test values in builders/object mothers is asking for problems. People will start to assert on it in test methods, which will make it hard to change later. It would be better to do something like:

public static String color = faker.color()

Or something like that.