What is the most user friendly / given-when-then convention compatible way to invoke pojo tests?

// given
PojoTester tester = new PojoTester();
PojoTester tester = new PojoTester(fieldValueChanger);
PojoTester tester = new PojoTester().using(fieldValueChanger);

Class coffee = Coffee.class;
Class cake = Cake.class;

Class[] classes = new Class[]{coffee, cake};

// when

// then
tester.test(coffee);
tester.testAll(coffee, cake,);
tester.testAll(classes);

OR

// given
Class coffee = Coffee.class;
Class cake = Cake.class;

Class[] classes = new Class[]{coffee, cake};

// when

// then
assertThat(class).using(fieldValueChanger).hasWellImplemented...();
assertThat(class1, class2).using(fieldValueChanger).haveWellImplemented...();

EXPLANATION

Currently test and testAll methods throw exception when pojo has invalid equals, hashcode or toString method implementation.

NESTED CLASSES

You can also define nested classes to change in your main class e.g.

A {
  B b;
  C c.
}
Class baseClass = A.class;
Class[] nestedClasses = new Class[]{B.class, C.class};

test(baseClass, nestedClasses )

KIND OF TESTS

There is no option to choose which tests should be run (equals, hashcode or toString). How do you want to provide it? E.g.

new PojoTester(EQUALS | HASHCODE | TO_STRING) or new PojoTester().addTesters(new EqualsTester(), ...) or assertThat(class).using(new HashCodeTester()).hasWellImplemented...();

CHANGING FIELDS

At this moment you can provide you own fieldsValuesChanger that should change field of specific type e.g. Coffee. In order to do this you have to extend AbstractFieldsValuesChanger class and implement some methods.

If you do not specify your own fields values changer and pojo tester could not change field value then it sets it either to null or class.instantiate()

Appears that this project is not in active maintenance. There are pull reviews open since 2017. If this is the case, may I suggest flagging it in the README.

In the interim, this fork https://github.com/obsidiandynamics/pojo-tester has been uplifted to support JDK 13.

This is a 2nd thought about fast testing of equals() and hashCode(). No EQUALS_FAST and HASH_CODE_FAST, now .testing(Method.EQUALS, Method.HASH_CODE).quickly() is used instead.

I have a test that from time to time fails in my Jenkins instance, but never failed on my local machine.

It fails with the following message:

Class EntityClass has bad 'hashCode' method implementation.
The hashCode method should return different hash codes for non equal objects.
Current implementation returns same hash codes.
Object:
EntityClass(f1=www.pojo.pl, f2=www.pojo.pl, f3=-4, f4=Fri Mar 10 14:52:19 UTC 2017, f5=www.pojo.pl, f6=www.pojo.pl)
and
EntityClass(f1=www.pojo.pl, f2=www.pojo.pl, f3=-4, f4=Fri Mar 10 14:52:19 UTC 2017, f5=www.pojo.pl, f6=www.pojo.pl)
should have different hash codes:
38708309
and
38708309

Class code:

@Getter
@ToString
@EqualsAndHashCode
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PACKAGE)
public class EntityClass {

    private String f1;
    private String f2;
    private int f3;
    private Date f4;
    private String f5;
    private String f6;
}

and this is my test

assertPojoMethodsFor(EntityClass.class)
        .testing(GETTER, TO_STRING, CONSTRUCTOR, EQUALS, HASH_CODE)
        .areWellImplemented();

I suspect the Date f4 field is the same and it is causing issues. BTW. Is there a way to change the test (as I cannot change the production code) so that when it fails, a custom message (provided function) is used instead of toString()? Something along these lines:

    assertPojoMethodsFor(EntityClass.class)
            .testing(GETTER, TO_STRING, CONSTRUCTOR, EQUALS, HASH_CODE)
            .areWellImplemented()
            .messageWhenFails((o1, o2) -> "o1 date" + o1.f4 + " and o2 date" + o2.f4);

Now it is possible to test equals() and hashCode() in quadratic rather than exponential time (and 20^2 is much better than 2^20 for a POJO with 20 fields corresponding to 20 columns in a DB table). The old thorough testers are preserved.

Use this setup to reproduce the bug. Two nested classes:

@Data
public class A {
    private long userId;
    private B withdraw;
}

@Data
public class B {
    private CurrencySymbol currency;
    private Money amount;
    private long account;
}

Now, here is how I test both classes in a single test case:

    @Test
    public void shouldTestEquals() {
        // given
        final Class[] classesUnderTest = { A.class,
                                           B.class};
        // when
        // then
        assertPojoMethodsForAll(classesUnderTest).create(Money.class, MONEY_CONSTRUCTOR_PARAMETERS)
                                                 .create(CurrencySymbol.class, CURRENCY_SYMBOL_CONSTRUCTOR_PARAMETERS)
                                                 .testing(Method.EQUALS)
                                                 .areWellImplemented();
    }

This results in the following error:

Class package.A has bad 'equals' method implementation.
The equals method should return false if objects should not be equal.
Current implementation returns true.
Object:
package.A@d7f2a
should not be equal to:
package.A@d7f2a
pl.pojo.tester.internal.assertion.equals.NotEqualEqualsAssertionError: 


Class package.A has bad 'equals' method implementation.
The equals method should return false if objects should not be equal.
Current implementation returns true.
Object:
package.A@d7f2a
should not be equal to:
package.A@d7f2a

Objects are obviously equal, I guess there might be a bug in generators.

So I'm basically doing the following on 0.7.6

assertPojoMethodsFor(IndexedTPE.class).quickly().areWellImplemented();

When I run the test inside of intelliJ I get this:

pl.pojo.tester.internal.assertion.hashcode.NotEqualHashCodeAssertionError: 


Class com.ciena.bp.nsi.indexingservice.model.tpe.IndexedTPE has bad 'hashCode' method implementation.
The hashCode method should return different hash codes for non equal objects.
Current implementation returns same hash codes.
Object:
IndexedTPE{resourcePartitionInfo=[], id=null, usedCapacity=[], active=null, networkConstruct=null, operationState=null, lastUpdatedState=null, expectations=[], userData=[], identifiers=[], deploymentState=null, lifecycleState=null, resourceState=null, bookingData=null, bookingData_lockout=null, plannedCapacity=[], attributePolicies=null, derivedAttributes=null, plannedAttributes=null, discoveredAttributes=null, extraData=IndexedTPEExtraData{usedCapacityPresent=false, eplServicePresent=false, ftpLagIsOnNni=false, ptpIsNniWithIpInterface=false, ftpLagIsOnNniWithIpInterface=false, ftpLagMultiChassis=false, interfaceIp=, clientTpesSize=0, tdmPortCapacity=true}}
and
IndexedTPE{resourcePartitionInfo=[], id=null, usedCapacity=[], active=null, networkConstruct=null, operationState=null, lastUpdatedState=null, expectations=[], userData=[], identifiers=[], deploymentState=null, lifecycleState=null, resourceState=null, bookingData=null, bookingData_lockout=null, plannedCapacity=[], attributePolicies=null, derivedAttributes=null, plannedAttributes=null, discoveredAttributes=null, extraData=IndexedTPEExtraData{usedCapacityPresent=false, eplServicePresent=false, ftpLagIsOnNni=false, ptpIsNniWithIpInterface=false, ftpLagIsOnNniWithIpInterface=false, ftpLagMultiChassis=false, interfaceIp=, clientTpesSize=0, tdmPortCapacity=true}}
should have different hash codes:
-172078917
and
-172078917

Not sure it matters, but when debugging, I get this instead:

pl.pojo.tester.internal.assertion.equals.NotEqualEqualsAssertionError: 


Class com.ciena.bp.nsi.indexingservice.model.tpe.IndexedTPE has bad 'equals' method implementation.
The equals method should return false if objects should not be equal.
Current implementation returns true.
Object:
IndexedTPE{resourcePartitionInfo=[], id=null, usedCapacity=[], active=null, networkConstruct=null, operationState=null, lastUpdatedState=null, expectations=[], userData=[], identifiers=[], deploymentState=null, lifecycleState=null, resourceState=null, bookingData=null, bookingData_lockout=null, plannedCapacity=[], attributePolicies=null, derivedAttributes=null, plannedAttributes=null, discoveredAttributes=null, extraData=IndexedTPEExtraData{usedCapacityPresent=false, eplServicePresent=false, ftpLagIsOnNni=false, ptpIsNniWithIpInterface=false, ftpLagIsOnNniWithIpInterface=false, ftpLagMultiChassis=false, interfaceIp=, clientTpesSize=0, tdmPortCapacity=true}}
should not be equal to:
IndexedTPE{resourcePartitionInfo=[], id=null, usedCapacity=[], active=null, networkConstruct=null, operationState=null, lastUpdatedState=null, expectations=[], userData=[], identifiers=[], deploymentState=null, lifecycleState=null, resourceState=null, bookingData=null, bookingData_lockout=null, plannedCapacity=[], attributePolicies=null, derivedAttributes=null, plannedAttributes=null, discoveredAttributes=null, extraData=IndexedTPEExtraData{usedCapacityPresent=false, eplServicePresent=false, ftpLagIsOnNni=false, ptpIsNniWithIpInterface=false, ftpLagIsOnNniWithIpInterface=false, ftpLagMultiChassis=false, interfaceIp=, clientTpesSize=0, tdmPortCapacity=true}}

Any suggestions? As far as I can tell the Objects really should be identical...

Testing a pojo with a Timestamp value, break the equals method and then the assertion return false. Here's a minimal example :

public class MyPOJO {
       private Timestamp timestamp;
}
    @Test
    public void pojosTest() {
        assertPojoMethodsForAll(MyPOJO.class).areWellImplemented();
    }

TODO refactor JavaTypeInstantiator.

• [x] Probably merge with ? PrimitiveInstantiator, StringClassInstantiator, JavaLangClassInstantiator ?
• [x] resolve todos
• [x] more refactor

In the project https://github.com/36893488147419103231/pojo-tester-tester in the package testertester.equalshashcode there are tests of 3 classes:

public class Small {
  int a,b,c
}
public class Medium {
  int a,b,c,d, e,f,g,h, i,j,k,l, m,n,o,p ,q,r,s,t, u;
}
public class Big {
  int a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
}

with equals() and hashCode() generated by IDE.

The first class is tested in no time, the second one takes about a minute, and the test for the third one did not terminate for me (but probably it would in about half an hour, unless it would take too much memory). UPD: bigTest failed after 8m 49s with java.lang.OutOfMemoryError: GC overhead limit exceeded.

It is important to test equals() and hashCode() in linear time.

I propose the following algorithm:

Start with 3 POJO objects, one filled with nulls (zeroes, etc.), and two others filled with values that do not repeat (well, it is difficult to find 20 different boolean values). Initially for the class MyPojo {int a,b,c,d;}we have:

null, null, null, null
P,Q,R,S
W,X,Y,Z

On the first iteration, we will compare P, null, null, null with:

null, null, null, null
P, null, null, null
W, null, null, null

On the second iteration, we will compare P, Q, null, null with:

P, null, null, null
P, Q, null, null
P, X, null, null

On the 3rd iteration, we will compare P, Q, R, null with:

P, Q, null, null
P, Q, R, null
P, Q, Y, null

and so on. Of course, you must check that a.equals(b) == b.equals(a), and that objects that are equal have equal hash codes. You may check that the number of different returned hash codes is at least a half of the the number of objects that participated in comparisons. I'd recommend performing additional comparisons on each iteration, e.g. that a.equals(null) == false, that a.equals(a) is true, and that a.equals(1) is false.

Note. This issue may be related on unrelated to https://github.com/sta-szek/pojo-tester/issues/201

(UPDATE) Note 2. I believe, it is FieldUtils.permutations() called from ObjectGenerator.generateDifferentObjects() that is responsible for exponential growth. It for N fields, it returns 2^N permutations. If it returned a list of size N, consumption of both time and memory would be linear.

Hello guys I have been noting that when adding multiple class to test using assertPojoMethodsForAll execution time grows exponentially. I am testing with 8 entities or dtos and test did not finish after 5 minutes. I had to kill process.

Please see attached sample project. pojo-test.zip

The code given below is a valid POJO. Java POJOs are allowed to return same hashCode() for non-equal objects. Might not be optimal, but it's valid and actually fairly common situation - see https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()

It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

However for a simple pojo listed below pojo-tester (v 0.7.6) throws:

Class (...)MyPojoTest.MyPojo has bad 'hashCode' method implementation.
The hashCode method should return different hash codes for non equal objects.

The test code:

package com.my.pojo;
import org.junit.jupiter.api.Test;
import java.util.Objects;
import static pl.pojo.tester.api.assertion.Assertions.assertPojoMethodsFor;

// hashCode() and equals() generated with IntelliJ
class MyPojoTest {

    public static class MyPojo {
        private String name;
        private int age;

        public String getName() {  return name;   }
        public void setName(String name) {  this.name = name; }

        public int getAge() {    return age;  }
        public void setAge(int age) { this.age = age;  }

        @Override
        public boolean equals(Object o) {
            if (this == o) {
                return true;
            }
            if (o == null || getClass() != o.getClass()) {
                return false;
            }
            MyPojo myPojo = (MyPojo) o;
            return age == myPojo.age &&
                    Objects.equals(name, myPojo.name);
        }

        @Override
        public int hashCode() {
            return Objects.hash(name);
        }
    }

    @Test
    public void testMyPojo() {
        assertPojoMethodsFor(MyPojo.class).areWellImplemented();
    }
}

I wrote the following, wrong class; pojo tester claims it's well implemented.

public class TestClass {

        @Nullable
        private Double testField;


        public TestClass(@Nullable Double testField) {
            this.testField = testField;
        }

        @Nullable
        public Double getTestField() {
            return testField;
        }

        public void setTestField(@Nullable Double testField) {
            this.testField = testField;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) {
                return true;
            }
            if (o == null || getClass() != o.getClass()) {
                return false;
            }
            TestClass that = (TestClass)o;
            if (!(testField == null && that.testField == null) || (testField != null && that.testField != null && Double.compare(testField, that.testField) != 0)) {
                return false;
            }
            return true;
        }

        @Override
        public int hashCode() {
            return Objects.hash(testField);
        }

        @Override
        public String toString() {
            final StringBuilder sb = new StringBuilder("TestClass {");
            sb.append("testField=").append(testField);
            sb.append('}');
            return sb.toString();
        }
    }

However, this simple test is enough to show the equals method is wrong:

        TestClass testClass = new TestClass(2d);
        TestClass testClass2 = new TestClass(2d);
        assertEquals(testClass, testClass2);

Hi folks, unfortunatelly I dont have time to maintain this project. As you proably noticed it is outdated, lots of issues are not solved and, what is really bad, CI/CD tool is not working anymore.

All this makes that releasing pojo-tester is not possible.

Let me know if anyone would like to contribute and update projects.

Thanks

Classpath may contain files with extensions which are not .class. For example my classpath contains .xml files (because MyBatis).

Currently ReflectionUtils.removeClassSuffix is called, that removes the .class suffix; however it should filter to consider .class files only before doing that.

Right now my.package.File.xml becomes my.package.Fi and that triggers an error when Class.forName is called on it.

Version: 0.7.6

I have a class (EntityUnderTest) which has only one property. If I initalize this object at either in the constructor of the EntityUnderTest or direct at declaration I'll get an NotEqualEqualsAssertionError error. If a remove the inilization the test passes.

Here is the EntityUnderTest

public class EntityUnderTest

    private ChildEntity faultInjectionParameters = new ChildEntity();

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        EntityUnderTest that = (EntityUnderTest) o;
        return Objects.equals(faultInjectionParameters, that.faultInjectionParameters);
    }

    @Override
    public int hashCode() {
        return Objects.hash(faultInjectionParameters);
    }

And the child entity

public class ChildEntity {

    private String string;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        ChildEntity that = (ChildEntity) o;
        return Objects.equals(string, that.string);
    }

    @Override
    public int hashCode() {
        return Objects.hash(string);
    }

}

I also added a short reprocuder here: https://github.com/jacobhampel/pojoTestReproducer

The error message says:

The equals method should return false if objects should not be equal

But the hashCode returns both the same value. So, I would expect that the test will pass.