Java Magazine, Nov/Dec 2016
ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 34 junit 5 map expected new IllegalStateException Expected exception expected was not thrown ifPresent ex throw ex case WAS_ THROWN_ AS_ EXPECTED the exception was thrown as expected so there is nothing to do case WAS_ THROWN_ NOT_ AS_ EXPECTED an exception was thrown but of the wrong type it was rethrown in handleTestExecutionException so there is nothing to do here Two details of this approach are worthy of debate here Is there a more appropriate exception than Illegal StateException For example perhaps an Assertion FailedError would be better If the wrong exception was thrown should I fail the test here I rethrew the exception in handleTestExecutionException so presumably it either failed the test already or was caught by some other extension that made the test pass So failing it might break that other extension Both topics are worthwhile pursuing to finish this feature But other than that were done with the extension to handle expected exceptions Timing out The original timeout guaranteed that JUnit 4 would abandon a test once the specified time ran out That requires pushing the test onto a separate thread Unfortunately JUnit 5 has no extension points interacting with threads so this is not possible One dire consequence is that there can be no extensions that run tests on specific threads such as the event dispatch thread for Swing tests or the application thread for JavaFX tests The JUnit team is well aware of this limitation Lets hope they address it soon You could implement an alternative feature that measures how long a test ran which implies that it must have finished and fail it if it was above the threshold With all I discussed so far this should be fairly straightforward Conclusion Weve seen that JUnit 5 provides specific extension points which are nothing more than small interfaces Extension developers can implement these interfaces and register their implementations directly with @ ExtendWith or more seamlessly with custom annotations During the test lifecycle JUnit pauses at each extension point searches for all extensions that apply to the current test node gathers context information and calls extensions in outside in order Extensions operate on the context and whatever state they persisted in the store JUnit reacts to the return values of the called methods and changes the tests behavior accordingly Weve also seen how you can put this together for a simple benchmark extension and for a more involved clone of JUnit 4 s @ Test annotation You can find these and more examples from me on GitHub If you have any questions or remarks to share let me know article Nicolai Parlog @ nipafx has found his passion in software development He codes for a living as well as for fun Parlog is the editor of SitePoints Java channel and blogs about software development on codefx org He also contributes to open source projects
You must have JavaScript enabled to view digital editions.
