Category Archives: JUnit 5

Interesting Features of JUnit 5

Since beginning to work with code in CS443 – Software Quality Assurance and Testing, we’ve used JUnit framework for designing and running our test cases. So I decided to search for a blog post discussing some interesting features that I may not have come across yet, but could be useful and landed upon Exploring the Exciting New Features of JUnit 5. This post is from December 2023, so it should be relatively up-to-date and I recall a conversation with Dr. Wurst at one point where he briefly mentioned considering switching to a newer version of JUnit for some attractive features – hopefully we can delve into some of these.

Several feature additions come with JUnit 5 and specifically version 5.4. One that immediately stood out to me was support for more/new annotations and assertions like @Nested. We’ve looked at some basic annotations like @BeforeEach and @AfterAll in class but the idea of nesting tests is newer – however it makes perfect sense from a practical perspective. Depending on the outcome of an initial test, testers may want to run further tests on one branch or two different tests depending on which branch is followed. Proper annotating likely helps the compiler recognize the nested nature of the tests preceded and manage potentially complex webs of nested tests most efficiently.

There’s also improvements to the assertEquals() functions and overall flexibility through enhancements to API and insertion features for handling Lambda functions. This goes hand in hand with a new feature of JUnit 5 – the ability for tests to be dynamically generated during test runtime and implemented (if needed) using a Factory class/method. Last semester in Software Construction Design and Architecture, we learned about the Factory architecture and methodology so it was cool to see it applied to enhance features in professional software. 

Another cool feature of JUnit 5 which represents a considerable change from JUnit 4 is the transition to a modular structure, meaning there is a separate test runner and classes which operate independently from the main program. I could imagine that this separation isolates any issues that may arise during testing and protect the main program, while also preventing any unintended interactions with the main from interacting with properly designed tests.

JUnit 5 offers some major features and enhancements over the previous versions with the ability to tag and implement nested tests, improved Lambda function support and Factory method for dynamic test creation and implementation. Considering these, I can see how JUnit could be effective for designing automated test runs. I’m looking forward to implementing more of these features in our class and homework activities for CS443, and trying some extra tests and methods that I read about in this.

Source: 

https://blog.machinet.net/post/exploring-the-exciting-new-features-of-j-unit-5

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

A Closer Look into JUnit 5

For my blog post this week I wanted to take a closer look into what to expect with JUnit 5. Last class, Professor Wurst gave us a brief run down on some of the nifty features and functionalities that were introduced in JUnit 4, such as testing for exceptions and implementing the assertThat() function. Seeing as the new JUnit framework, JUnit 5, was just released this past August I though it would be interesting to take a look into what additional features were added into this new JUnit testing framework. I found this blog post, A Look at JUnit 5’s Core Features & Testing Functionality, written by Eugen Paraschiv, a software engineering professional and thought it gave a pretty good run down on what to expect with JUnit 5.

Paraschiv points out a few new and useful assertions that are implemented in the JUnit 5 testing framework; assertAll(), assertArrayEquals(), assertIterableEquals(), and assertThrows(). Assert-all is a pretty useful assertion because it allows you to group all assertions within one test case together and report back the expected vs. actual results for each assertion in your test case using a MultipleFailuresError object, which makes understanding why your test case failed easier. Next, the assert-array-equals and assert-iteratable-equals assertions are also highly useful as they allow you test whether or not your particular data structure (array, list, etc..) contains the elements that you expected it to. In order to use these assertions, however, the objects in your data structure must implement the equals() method. Finally, the test-throws assertion pretty much does what the “@Test(expected = SomeException.class)” annotation did in JUnit 4. I like this way of checking for exceptions much better though because it seems more intuitive and makes the test case easier to read.

In his blog post, Eugene brings up a lot of cool new features implemented in JUnit 5 but the two that really stood out to me were (1) the introduction to the concept of assumptions and (2) conditional test execution. First, assumptions are new to JUnit 5 and I think that they could prove extremely useful in practice. Essentially, assumptions are syntactically similar to assertions (assumption methods: assumeTrue(), assumeFalse(), assumingThat() ) but they do not cause a test to pass or fail. Instead, if an assumption within a test case fails, then the test case simply does not get executed.  Second, conditional test execution is another cool new feature introduced in JUnit 5. JUnit 5 allows you to define custom annotations which can then be used to control whether or not a test case gets executed. I though the idea of writing your own test annotations was really interesting and I could definitely see this being useful in practice.

 

 

 

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.