I was very pleased to read that Mockito finally integrates nicely with JUnit 5 via its shiny new MockitoExtension – about time!
Good news Everyone!™ The number one testing framework in the Java ecosystem has moved a major step forward: JUnit 5 final is available since yesterday and brings lots of major improvements for the way you implement your test cases!
And of course, TestEE.fi offers JUnit 5 integration since day one! And of course, it’s just as easy to functional test your Java-EE applications with TestEE.fi as it was with JUnit 4.
A common pattern to communicate with backend systems today are RESTful HTTP resources, usually using JSON as the payload format. The standard for exposing your application’s functionality in a Java-EE application as REST resources is JAX-RS.
TestEE.fi allows you to test your application including your REST resources by combining the awesome and speedy Jetty servlet container with the JAX-RS reference implementation Jersey and integrating it seamlessly with the features you’ve already made yourself acquainted with in the previous installments.
The previous posts in this series introduced how TestEE.fi makes it really easy to test the functional behavior of your Java-EE applications with JUnit 4. While JUnit surely is the most common Java framework to write and execute your tests with, it’s far from being the only one. One at least equally interesting framework for Behavior Driven Development (BDD) that TestEE.fi integrates nicely with is Cucumber JVM. Continue reading
Many if not most Java-EE applications use a SQL database for persisting application state. The well established technologies for accessing a SQL based datastore from Java are JDBC and JPA, both of which are an integral part of the Java-EE standard today.
TestEE.fi helps you functional testing your Java-EE application including JDBC and JPA persistence in a very easy and convenient way that’s still highly extendable and customizable. And it integrates with state-of-the-art tooling like Flyway and Liquibase to help you set up your database for testing the same way you do in production.
Functional testing Java-EE applications often requires validating the behavior of your business logic in interaction with one or more surrounding systems. Usually it’s not desirable to actually interact with these systems from your automated functional test cases as this can introduce non-deterministic behavior and jeopardizes repeatability – two very important aspects of solid testing.
I am a strong advocate of Test Driven Development. I strongly believe that, in order to deliver good software quality at sustainable speeds, you must have good tests.
Writing meaningful tests for a Java-EE application traditionally has been a rather cumbersome task. While mocking Frameworks like Mockito make it rather easy to test your classes in isolation, this kind of test usually has only limited value: while ensuring that the class in question does what it’s supposed to do, that alone does not guarantee you any desired system behavior exhibited by your application.
Use-case testing in Java-EE
In order to automatically test meaningful behavior your stakeholders are interested in, you usually have to consider a whole business use-case. In an application that usually means testing a number of classes working together, preferably in conjunction with some in-memory SQL database like H2. Other systems your application has to communicate with in order to fulfill the use-case usually have to be replaced with mocks to make your tests deterministic and repeatable. Continue reading