A new article by Java Champion Adam Bien, now up on otn/java, titled “Integration Testing for Java EE,” explores the intricacies of integration testing, which is done after a successful execution of unit tests, which however, will often fail. According to Bien, unit tests are fast and fine-grained while integration tests are slow and coarse-grained.

From the article:

“Testing everything inside an embedded container is convenient but unproductive. Java EE 6 components are annotated Plain Old Java Objects (POJOs) and can be easily unit tested and mocked out (see my previous article, “Unit Testing for Java EE.") with Java SE tools such as JUnit, TestNG, or Mockito. Using an embedded container to test your business logic is not only unproductive, but it is also conceptually wrong. Unit tests should validate your business logic, not the container behavior. Also, the majority of integration tests could be easily performed with a local EntityManager (see Listing 1) or a mocked-out container infrastructure. Only a fraction of all integration tests can be beneficially implemented with embeddable containers or test frameworks such as Arquillian.”

Read the complete article here.

A new article by systems architect Manfred Riem, now up on otn/java, titled “Working with Java SE 7 Exception Changes,” covers important developments in Java 7’s Project Coin, focusing on exception handling -- specifically multi-catch, rethrow, and try-with-resources. Project Coin consists of the following small language changes, which are intended to simplify common programming tasks: strings in switch statements; better integral literals; multi-catch exceptions; improved type inference for generic instance creation; try-with-resources; and simplified varargs method invocation.

From the article itself:

“The exception handling changes in Java SE 7 allow you not only to program more concisely, as demonstrated in the multi-catch examples, but they also allow you to partially handle an exception and then let it bubble up, as covered in the re-throw examples. Java SE 7 also facilitates less error-prone exception cleanup…”

Read the complete article here.

A new article, titled “Unit Testing for Java EE,” by Java Champion Adam Bien, is up on otn/java’s front page. Bien points out that too many developers believe that testing Java EE applications is too hard, inconvenient, or complex, something that has not been true since the advent of Java EE 5 more than five years ago.

Bien explains: “There is nothing special about unit testing Java EE 6 applications. You only have to add the JUnit library into your pom.xml file (see Listing 5) and put your classes into the src/test/java directory. All JUnit tests will be executed automatically during the standard Maven lifecycle: mvn clean install.”

He goes on to make use of “Mockito” an easy-to-use, open source mocking library. Bien writes:

“Mockito is able to create ‘smart proxies’ (a.k.a. mocks) from classes or interfaces. These proxies do not come with any behavior, but they are still perfectly usable. You can invoke methods, but will get the default values, or null, back. The behavior of the mocks can be recorded after their creation with when(mock.getAnswer()).then(42) syntax.

Mockito is perfectly suitable for ‘simulating’ any inconvenient classes, resources, or services. You can start with Mockito just by knowing a single class org.mockito.Mockito. The when-then ‘domain specific language’ is composed of static methods from the Mockito class. The org.mockito.Mockito class is well documented. In fact, the whole documentation set was generated from the JavaDoc markup in the org.mockito.Mockito class.”

Read the complete article here.