Java Reference
In-Depth Information
15.1.1. Testing strategies
In this section we're going to briefly introduce and give examples of testing your EJBs
using the three different testing strategies: unit testing, integration testing, and functional
testing. Each strategy has its specific purpose and exists to test your application in different
ways. No testing strategy is 100% complete by itself, and not even the combination of all
three strategies is guaranteed to find everything that may go wrong with your application.
But combining all three will give you assurance that you application is working the way
it's supposed to. So let's start with the first testing strategy, unit testing.
Unit testing
The purpose of unit testing is to exercise the application's business logic by feeding it dif-
ferent input and examining the output to assert that the results are correct. Although this
sounds simple and straightforward, unit testing can be very complicated and difficult to im-
plement, especially with older code.
There are a wide variety of techniques for unit testing. All techniques, however, tend to
have these fundamental principles in common:
1
. No connections to outside resources are allowed (databases, web services, and so
on).
2
. Test only a single class at a time.
3
. Test only a class's public contract (public methods or interface) and vary test input
data to cover any private code.
4
. Mock dependencies to return the data required to test the business logic of the class
being tested.
JUnit is a popular testing framework for Java applications. Mockito is a powerful and easy-
to-use framework for mocking a class's dependencies for unit tests. These two technolo-
gies, combined with the convention-over-configuration and POJO models of EJBs, have
made unit testing EJBs much easier.
Although unit testing is a good start for ensuring code quality, it won't tell you the whole
story. Once your application is deployed to a Java EE server, it gets turned into something
