Hi friends of a good test
I will not have access to a computer for a few weeks and thus wanted to give you a status report of the JUnit 5 migration of openmrs-core.
I will be able to respond on talk / review a few things on GitHub but I cannot try things out myself. I hope the community will support @achilep so we can get the migration over the finish line
What we have achieved:
- migrated almost all api package tests to JUnit 5. Remove PowerMock since that does not work on JUnit 5. We keep a few JUnit 4 tests (they have JUnit 4 in the name) around to ensure module devs can still write JUnit 4 tests until it is completely removed from openmrs-core.
- improved a bunch of assertions
- found broken test that was not running
- found parametrized test that was not running anything
- documented the steps and things we learned so far in the migration guide https://wiki.openmrs.org/display/docs/How+to+migrate+to+JUnit+5
- improved the unit testing convention doc https://wiki.openmrs.org/display/docs/Unit+Testing+Conventions (I have a plan of how to rewrite the entire https://wiki.openmrs.org/display/docs/Unit+Tests section; I just need a few months )
Here is what is left in my opinion:
-
2 tests are failing on Windows (are disabled on Windows but run on any other OS thus Travis CI/Bamboo CI). Either the tests have a flaw, there is an actual bug or the API we are testing does not make it easy to do the right thing. For more, on what we think is the cause and what we tried see tests failing in core on Windows
-
adapt javadocs of helper classes to signal deprecation and transition to JUnit 5
-
Migrate a module so we uncover any other unknown issues and show how module devs can migrate https://issues.openmrs.org/browse/TRUNK-5818
-
Finish the migration guide, incorporate feedback from the first brave module devs migrating to JUnit 5
-
Update the Unit Testing docs relating Assertions. I already adopted/flagged the deprecated JUnit 4 APIs; we need to adapt package names. Probably provide JUnit 4 & 5 package names for important things. Since some devs will still work on JUnit 4 tests outside of openmrs-core.
-
I think we do not have tests in openmrs-core that test the test helpers like @StartModule, BaseModuleContextSensitiveTest, BaseModuleWebContextSensitiveTest from the modules perspective. @StartModule at least when I look on GitHub in the openmrs org does not seem to be used often but still. Our APIs should be tested so we ensure it works for our consumers. We cannot write a test extending BaseModuleContextSensitiveTest in the api or web package since it would create another ehCache with name hibernateCache. You can only have one per JVM with this name.
And very important: not reintroduce JUnit 4 tests into openmrs-core. I added a test that checks tests for the JUnit 4 @Test
. It should fail if anyone tries to add such a test. If you need to add a JUnit 4 test for backwards compatibility reasons for module devs you will need to add it to the exclusion list. We cannot yet remove the JUnit 4 dependency since
we allow module devs to migrate at their own pace. So we provide JUnit 4 & 5 BaseModuleContextSensitiveTest, BaseModuleWebContextSensitiveTest
Thank you for your support and patience with the occasional hiccup of a failing pipeline.
JUnit 5 has some great features we can familiarize ourselves with and start using. Here is only a handful to get you excited