Java testing framework for testing pojo methods. It tests equals, hashCode, toString, getters, setters, constructors and whatever you report in issues ;)
The bugs that are not detected are shown below (the code without bugs is omitted):
public class Bad4b {
int qp;
int db;
public void setDb(int db) {
this.db = qp; // bug
}
}
public class Bad3a {
int qp;
int db;
public int getQp() {
return db; // bug
}
public int getDb() {
return qp; // bug
}
}
public class Bad2c {
int qp;
int db;
public int getDb() {
return qp; // bug
}
}
public class Bad2a {
int qp;
int db;
public int getQp() {
return db; // bug
}
}
In practice the bugs of this sort occur as a result of human error in copied&pasted code.
The problem with pojo-tester is that it tests getters when the object is filled with nulls. If all fields are set to null (or 0), whatever field you read from, you will get null.
The test of Bad4b succeeds most likely because the same value is passed to different setters. The difference between the tests of Bad4a and Bad4b is only in the order in which buggy and not-buggy setters are called; bad4aTest fails (which is ok), while bad4bTest succeeds (which is wrong).
In the project https://github.com/36893488147419103231/pojo-tester-tester there is a number of classes with buggy getters and setters.
The bugs that are not detected are shown below (the code without bugs is omitted):
In practice the bugs of this sort occur as a result of human error in copied&pasted code.
The problem with pojo-tester is that it tests getters when the object is filled with nulls. If all fields are set to null (or 0), whatever field you read from, you will get null.
The test of Bad4b succeeds most likely because the same value is passed to different setters. The difference between the tests of Bad4a and Bad4b is only in the order in which buggy and not-buggy setters are called; bad4aTest fails (which is ok), while bad4bTest succeeds (which is wrong).