The problems in WindowsUnitTest jobs in CI are caused by various unit tests that are either bugged or should be moved to IntegrationTests.
I found 3 tests named *IntegrationTests in src/test that need to move: * geode-core/src/test/java/org/apache/geode/distributed/internal/InternalDistributedSystemIntegrationTest.java * geode-protobuf/src/test/java/org/apache/geode/internal/protocol/protobuf/v1/operations/OqlQueryRequestOperationHandlerIntegrationTest.java * geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherIntegrationTest.java These are unit tests that are better off renamed and moved to src/integrationTest because they touch so many Geode classes including singletons: * geode-core/src/test/java/org/apache/geode/distributed/internal/InternalLocatorTest.java * geode-core/src/test/java/org/apache/geode/distributed/internal/locks/DLockServiceJUnitTest.java This one creates a full DistributedSystem stack so it belongs in src/integrationTest: * geode-core/src/test/java/org/apache/geode/distributed/internal/InternalDistributedSystemTest.java And these unit tests create a full Cache stack so they belong in src/integrationTest: * geode-lucene/src/test/java/org/apache/geode/cache/lucene/FlatFormatPdxSerializerJunitTest.java * geode-protobuf/src/test/java/org/apache/geode/internal/protocol/protobuf/v1/serialization/codec/JsonPdxConverterJUnitTest.java And one last unit test that I was able to fix -- this test creates a spy to test as a partial mock with a common goof that results in a full Cache being created and then not used by the test: * extensions/geode-modules/src/test/java/org/apache/geode/modules/util/BootstrappingFunctionTest.java I filed a PR to fix all of the above issues: https://github.com/apache/geode/pull/5011 Thanks, Kirk On Mon, Apr 27, 2020 at 1:58 PM Kirk Lund <kl...@pivotal.io> wrote: > This test started failing consistently on Windows (5 builds in a row so > far!): > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > > The method testNewSSLConfigSSLComponentLocator is the first > in SocketCreatorFactoryJUnitTest to execute. And because a previous unit > test initialized the singleton either directly or indirectly without > cleaning it up in tearDown, it pollutes the JVM for later tests. The only > later unit test that is affected seems to be SocketCreatorFactoryJUnitTest. > > Now you could easily fix SocketCreatorFactoryJUnitTest by adding a new > setUp() method: > > > *@Before* > *public void setUp() throws Exception {* > * SocketCreatorFactory.close();* > *}* > > @After > public void tearDown() throws Exception { > SocketCreatorFactory.close(); > } > > *This change will fix this specific symptom, but not the underlying > problem -- which is "previous unit test initialized SocketCreatorFactory > without cleaning it up". * > > *You can see why it's a problem if a unit test fails to cleanup EVERYTHING > that it setup. And you can why singletons (especially internal non-User API > singletons) are so dangerous for maintaining a clean GREEN CI.* > > Cheers, > Kirk > >
