Description
For now, the engine considers method invocations or field access on null values as producing NullPointerException. Previously in #226 such NPE checks were disabled for final fields from library classes because it often leads to the generation of tests with exceptions that are unexpected for a user with high usage of Java reflection. It is suggested to extend such a strategy to non-public fields from library classes too, for the same reasons.
Expected behavior
Consider generating tests for such a method:
publicclassDateExample {
booleanfoo(Datedate) {
returndate.getTime() == 100;
}
}Only such 3 tests are expected by user:
@Test@DisplayName("foo: return date.getTime() == 100 : False -> return date.getTime() == 100")
publicvoidtestFoo_DateGetTimeNotEquals100() {
DateExampledateExample = newDateExample();
Datedate = newDate(-155L);
booleanactual = dateExample.foo(date);
assertFalse(actual);
}
@Test@DisplayName("foo: return date.getTime() == 100 : True -> return date.getTime() == 100")
publicvoidtestFoo_DateGetTimeEquals100() {
DateExampledateExample = newDateExample();
Datedate = newDate(100L);
booleanactual = dateExample.foo(date);
assertTrue(actual);
}
@Test@DisplayName("foo: return date.getTime() == 100 : True -> ThrowNullPointerException")
publicvoidtestFoo_DateGetTime() {
DateExampledateExample = newDateExample();
assertThrows(NullPointerException.class, () -> dateExample.foo(null));
}But for now, UtBot also generates at least 2 such tests:
@Test@DisplayName("foo: return date.getTime() == 100 : True -> ThrowNullPointerException")
publicvoidtestFoo_ThrowNullPointerException() throwsException {
DateExampledateExample = newDateExample();
Datedate = ((Date) createInstance("java.util.Date"));
ObjectimmutableGregorianDate = createInstance("sun.util.calendar.ImmutableGregorianDate");
setField(immutableGregorianDate, "date", null);
setField(date, "cdate", immutableGregorianDate);
assertThrows(NullPointerException.class, () -> dateExample.foo(date));
}
@Test@DisplayName("foo: return date.getTime() == 100 : True -> ThrowNullPointerException")
publicvoidtestFoo_ThrowNullPointerException_1() throwsClassNotFoundException, Exception {
ClassdateClazz = Class.forName("java.util.Date");
BaseCalendarprevGcal = ((BaseCalendar) getStaticFieldValue(dateClazz, "gcal"));
BaseCalendarprevJcal = ((BaseCalendar) getStaticFieldValue(dateClazz, "jcal"));
try {
setStaticField(dateClazz, "gcal", null);
setStaticField(dateClazz, "jcal", null);
DateExampledateExample = newDateExample();
Datedate = ((Date) createInstance("java.util.Date"));
ObjectimmutableGregorianDate = createInstance("sun.util.calendar.ImmutableGregorianDate");
LocalGregorianCalendar.Datedate1 = ((LocalGregorianCalendar.Date) createInstance("sun.util.calendar.LocalGregorianCalendar$Date"));
setField(date1, "zoneinfo", null);
setField(date1, "normalized", false);
setField(date1, "millis", 0);
setField(date1, "seconds", 0);
setField(date1, "minutes", 0);
setField(date1, "hours", 0);
setField(date1, "dayOfMonth", 0);
setField(date1, "month", 0);
setField(date1, "gregorianYear", 11564545);
setField(immutableGregorianDate, "date", date1);
setField(date, "cdate", immutableGregorianDate);
dateExample.foo(date);
} finally {
setStaticField(Date.class, "gcal", prevGcal);
setStaticField(Date.class, "jcal", prevJcal);
}
}These tests SHOULD NOT be generated (in the plugin, at least).
Environment
No mocks, Java.
Potential alternatives
Unknown.
Context
We can possibly lose some branches with such disabling.
Description
For now, the engine considers method invocations or field access on null values as producing
NullPointerException. Previously in #226 such NPE checks were disabled for final fields from library classes because it often leads to the generation of tests with exceptions that are unexpected for a user with high usage of Java reflection. It is suggested to extend such a strategy to non-public fields from library classes too, for the same reasons.Expected behavior
Consider generating tests for such a method:
Only such 3 tests are expected by user:
But for now, UtBot also generates at least 2 such tests:
These tests SHOULD NOT be generated (in the plugin, at least).
Environment
No mocks, Java.
Potential alternatives
Unknown.
Context
We can possibly lose some branches with such disabling.