blog.codeleak.pl

Parameterized tests are used to test the same code under different conditions. One can set up a test method that retrieves data from a data source. This data source can be a collection of objects, external file or maybe even a database. The general idea is to make it easy to test different conditions with the same test method to avoid duplication and make the code easier to read and maintain. Jest has a built-in support for tests parameterized with data table that can be provided either by an array of arrays or as tagged template literal .

The general practices say that automated tests should be able to run independently and with no specific order as well as the result of the test should not depend on the results of previous tests. But there are situations where a specific order of test execution can be justified, especially in integration or end to end tests. By default, in JUnit 5 the execution of test methods is repeatable between builds hence deterministic but the algorithm is intentionally non-obvious (as authors of the library state). Fortunately, execution order can be adjusted to our needs using either built-in method orderers or by creating custom ones.

JUnit 4 TemporaryFolder @Rule allowed developers to create tests utilizing temporary directories. With JUnit 5, the @Rule s are not supported hence testing files and directories requireds a little bit of additional work. Fortunately, with JUnit 5.4 there is a new built-in extension to handle temporary directories in tests. And it is extremely easy to use.

JUnit 5 brings a lot of improvements in the assertions library, mainly thanks to Java 8 and Lambda Expression support and thanks to the presence of the new assertions like assertAll , assertTimeout or assertThrows . Although I really like JUnit 5 I believe that AssertJ is still a must in production grade unit tests and I will continue using it. But I think there are potential scenarios of mixing both JUnit 5 and AssertJ in single unit test: one of them is mixing JUnit assertAll with AssertJ assertThat .

The general idea of parameterized unit tests is to run the same test method for different data. Creating parameterized tests in JUnit 4 is far from being perfect. There are many issues with the existing architecture: parameters are defined as class fields and constructor is needed to create them, parameterized and non-parameterized tests cannot be mixed in one test class and built-in data sources are very limited. Fortunately, all of this is improved in JUnit 5!

One of the rules of writing good unit test is that it should fail for one reason, so unit test should test one logical concept. Sometime it is quite tough to have a single assertion per test. To follow the rule, we may have having multiple assertions per object in a single test. The problem with multiple assertions in a single test though, is that if the first one fails for any reason we actually don’t know about other assertions as they will not be executed. And you know the drill: you check assertion failure reason, you fix it and re-run the test. Maybe you are lucky and the test will pass. But maybe it will fail with another assertion. With really fast unit tests this is not a big issue but when it comes to, for example, Selenium tests analysis and failure detection can become cumbersome and for sure time consuming. Fortunately, we can re-think the way we create assertions in our tests thanks to AssertJ’s SoftAssertions .

AssertJ 3.0.0 release for Java 8 makes testing exceptions much easier than before. In one of my previous blog post I described how to utilize plain Java 8 to achieve this, but with AssertJ 3.0.0 much of the code I created may be removed. Warning: this blog post contains mostly the code examples.

Web integration tests allow integration testing of Spring Boot application without any mocking. By using @WebIntegrationTest and @SpringApplicationConfiguration we can create tests that loads the application and listen on normal ports. This small addition to Spring Boot makes much easier to create integration tests with Selenium WebDriver.

Testing with Files and directories in JUnit is easy thanks to TemporaryFolder @Rule . In JUnit rules ( @Rule ) can be used as an alternative or an addition to fixture setup and cleanup methods ( org.junit.Before , org.junit.After , org.junit.BeforeClass , and org.junit.AfterClass ), but they are more powerful, and can be more easily shared between projects and classes.

I sometimes use FizzBuzz to demonstrate the basics of unit testing to newbies. Although FizzBuzz is really simple problem, it can also be used to demonstrate more advanced unit testing techniques like implementing parametrized tests .

Whilst building a Spring Boot application you may encounter a need of adding a mail configuration. Actually, configuring the mail in Spring Boot does not differ much from configuring it in Spring Bootless application. But how to test that mail configuration and submission is working fine? Let’s have a look.

In JUnit there are many ways of testing exceptions in test code, including try-catch idiom , JUnit @Rule , with catch-exception library. As of Java 8 we have another way of dealing with exceptions: with lambda expressions. In this short blog post I will demonstrate a simple example how one can utilize the power of Java 8 and lambda expressions to test exceptions in JUnit.

Constructing objects in tests is usually a painstaking work and usually it produces a lot of repeatable and hard to read code. There are two common solutions for working with complex test data: Object Mother and Test Data Builder . Both has advantages and disadvantages, but (smartly) combined can bring new quality to your tests.

Inspired by the @tkaczanowski talk during GeeCON conference I decided to have a closer look at custom assertions with AssertJ library.

There are many ways of handling exceptions in JUnit ( 3 ways of handling exceptions in JUnit. Which one to choose? , JUnit ExpectedException rule: beyond basics ). In this post I will introduce catch-exception library that I was recommended to give a try. In short, catch-exceptions is a library that catches exceptions in a single line of code and makes them available for further analysis.

JUnit itself is not enough for most of today's Java projects. You also need a mocking library, maybe something else. In this mini HOW-TO I present the test dependencies you can start with in a new Java project.

There are different ways of handling exceptions in JUnit tests. As I wrote in one of my previous posts , my preferable way is using org.junit.rules.ExpectedException rule. Basically, rules are used as an alternative (or an addition) to methods annotated with org.junit.Before , org.junit.After , org.junit.BeforeClass , or org.junit.AfterClass , but they are more powerful, and more easily shared between projects and classes. In this post I will show more advanced usage of org.junit.rules.ExpectedException rule.

Parameterized unit tests are used to to test the same code under different conditions. Thanks to parameterized unit tests we can set up a test method that retrieves data from some data source. This data source can be a collection of test data objects, external file or maybe even a database. The general idea is to make it easy to test different conditions with the same unit test method, which will limit the source code we need to write and makes the test code more robust. We can call these tests data-driven unit tests. The best way to achieve data-driven unit tests in JUnit is to use a JUnit's custom runner - Parameterized or JUnitParams' JUnitParamsRunner . Using JUnit's approach may work in many cases, but the latter seems to be more easy to use and more powerfull.