Describe the bug
When a POJO contains multiple fields of the same type (e.g., String), the library seems to use the exact same generated test value for all of them. This leads to false positives in the test results if a getter erroneously returns the wrong field (a typical copy-paste error). The test passes even though the getter is pointing to the wrong variable.
To Reproduce
Here is a minimal reproducible example:
public class MyBean {
private String fieldA;
private String fieldB;
public void setFieldA(String fieldA) {
this.fieldA = fieldA;
}
public String getFieldA() {
return fieldA;
}
public void setFieldB(String fieldB) {
this.fieldB = fieldB;
}
// BUG: Copy-paste error, returns fieldA instead of fieldB
public String getFieldB() {
return fieldA;
}
}
Test Execution:
Java
@Test
void testPojo() {
assertPojoMethodsForAll(MyBean.class)
.testing(Method.GETTER, Method.SETTER)
.areWellImplemented();
}
Expected behavior
The test should fail because getFieldB() does not return the value that was passed to setFieldB().
Actual behavior
The test passes.
Suspected Cause
The internal value generator assigns the exact same string value to both fieldA and fieldB. When getFieldB() returns fieldA, the assertion passes because both fields happen to hold the identical generated value.
Suggested Fix
The default value generators should ensure that unique values are created for every field (e.g., by appending a UUID, a counter, or the field name to the generated string), so that fieldA and fieldB hold distinct states during the test.
Describe the bug
When a POJO contains multiple fields of the same type (e.g.,
String), the library seems to use the exact same generated test value for all of them. This leads to false positives in the test results if a getter erroneously returns the wrong field (a typical copy-paste error). The test passes even though the getter is pointing to the wrong variable.To Reproduce
Here is a minimal reproducible example:
Expected behavior
The test should fail because getFieldB() does not return the value that was passed to setFieldB().
Actual behavior
The test passes.
Suspected Cause
The internal value generator assigns the exact same string value to both fieldA and fieldB. When getFieldB() returns fieldA, the assertion passes because both fields happen to hold the identical generated value.
Suggested Fix
The default value generators should ensure that unique values are created for every field (e.g., by appending a UUID, a counter, or the field name to the generated string), so that fieldA and fieldB hold distinct states during the test.