Many tests in the Eclipse Platform and Platform UI projects still rely on JUnit 3. While some of them are easy to migrate, in particular the ResourceTest implementation are problematic because they heavily rely on inheritance of utilities and common setup/teardown functionality. In addition, the WorkspaceSessionTests as specific ResourceTests have a custom implementation for their execution that depends on JUnit 3 API.
While JUnit 3 is quite outdated and should thus be replaced, the real issue with those tests is the inheritance hierarchy. All tests use a bunch of setup functionality and quite generic teardown functionality in the sense of a "catch all" manner rather than precisely specifying what each test class needs to set up and tear down. This can easily be realized by rules in JUnit 4 or extensions in JUnit 5.
Expected Situation
All tests in Platform and Platform UI shall be migrated to JUnit 4 or JUnit 5. Finally, the CoreTest class in the test harnes may be deprecated.
Current Situation
Many tests in the Eclipse Platform and Platform UI projects still rely on JUnit 3. While some of them are easy to migrate, in particular the
ResourceTest
implementation are problematic because they heavily rely on inheritance of utilities and common setup/teardown functionality. In addition, theWorkspaceSessionTests
as specificResourceTests
have a custom implementation for their execution that depends on JUnit 3 API.While JUnit 3 is quite outdated and should thus be replaced, the real issue with those tests is the inheritance hierarchy. All tests use a bunch of setup functionality and quite generic teardown functionality in the sense of a "catch all" manner rather than precisely specifying what each test class needs to set up and tear down. This can easily be realized by rules in JUnit 4 or extensions in JUnit 5.
Expected Situation
All tests in Platform and Platform UI shall be migrated to JUnit 4 or JUnit 5. Finally, the
CoreTest
class in the test harnes may be deprecated.