equals method should not be overriden on interfaces

[akutschera]

While working on a fix for #102 I noticed that the following test fails:

    @RepeatedTest(10)
    void issue103() {
        var sut = Fixture.fixture().create(Closeable.class);

        assertThat(sut).isEqualTo(sut);
    }

This fails for interfaces and abstract classes because we create a proxy that returns a random value for any called method.

You have to run it multiple times, because the result of equals is a random boolean, so for some created fixtures it's true, for others it's false.
If we create random values for this, we violate the Java contract for equals and hashCode. This might lead to unexpected behaviour.
I believe this should be fixed before the fix for #102 can be merged.

[akutschera]

I propose that when we construct a proxy for interfaces or abstract classes, we only fixture abstract methods. Everything else should be forwarded to the existing (parent) classes.
That has the advantage that the fixtured objects are closer to real-life instances, even though we will have to write a bit more code in the ProxyInvocationHandler.

[Nylle]

Only fixturing the abstract methods should not be hard. This can easily be reflected - maybe the SpecimenType already has this? (I'm not sure.)
If we can rely on the "existing parent class" (I don't know what this would be on an interface), I'd agree to your proposal.

Edit: yes, SpecimenType has a helper for abstract, but it only applies to the type itself - to analyse methods we'd have to write a little something.

[akutschera]

For interfaces I want to keep the default methods. If we call these instead of fixturing, we should be fine. Maybe in the future there will be a need to fixture these, but that still needs to be separated from fixturing equals or hashCode.
Besides, we do not overwrite existing methods anywhere else so not doing that in abstract classes or interfaces would actually make JavaFixture more predictable (as in: less surprising).

[akutschera]

The commits above should fix that. As a bonus, when concrete methods throw an exception, the caller will see it.

[Nylle]

(Will be closed as resolved with the next release.)

[jk-idealo]

Fixed since version 2.11.0.