Although we put JUnit4 4.13.2 on the classpath when running the generated tests (matching what EvoSuite 1.2.0 specifies), we sometimes (so far for mvnc builds, though not for obfs) see that a slightly different version of JUnit4 gets run: 4.13.1, 4.12, or 4.13.
The class-under-test's own dependencies appear earlier in the classpath than the 4.13.2 jar, so presumably this different version is being pulled in because the class-under-test explicitly depends on a different JUnit4 version.
- Check whether this is the reason.
- Decide what (if anything) we should do. Options are:
- Nothing (let the class-under-test's JUnit4 version win) or
- Force 4.13.2 each time by moving it earlier in the classpath.
I think probably (i) is the right choice, but neither's perfect.
Although we put JUnit4 4.13.2 on the classpath when running the generated tests (matching what EvoSuite 1.2.0 specifies), we sometimes (so far for mvnc builds, though not for obfs) see that a slightly different version of JUnit4 gets run: 4.13.1, 4.12, or 4.13.
The class-under-test's own dependencies appear earlier in the classpath than the 4.13.2 jar, so presumably this different version is being pulled in because the class-under-test explicitly depends on a different JUnit4 version.
I think probably (i) is the right choice, but neither's perfect.