Some time ago, we had a look at the mocking framework Mockito. Today I want to introduce the competitor JMockit and try to answer the question why and when to use one framework over the other.
Java, Web and Mobile
In my current project I work in the QA-team. One of the questions we have to answer was, “How can we test a rest webservice?” With REST Assured, we found an easy way to test the service from various aspects. This tutorial explains how.
The first part of this post introduced parameterized tests to avoid missing or unnecessary translation resources. I also showed an example of a possibly parameterized test, which was to outline how good test failure design helps to find all errors instead only the first or have static variables.
Unit testing is essential to produce good software. As a unit test is intended to cover only a very small piece of code we need to mock out other components. This post provides an introduction into the widely used mocking framework Mockito.
Being part of a software development team, bound to an organization leads to a variety of agreements. As a Java developer I often adhere to the mature rules from Effective Java (Joshua Bloch) or from the Design Patterns Book of the Gang of Four (Erich Gamma et al). To bring that idea to future developers I often use Unit tests to express the common sense behind these rules as code. And I don’t overdo it but use parameterized tests excessively. So my code does not only contain the technical solution to a functional requirement and the necessary unit tests. In addition I provide unit tests for the non functional requirements. As an introduction I chose internationalization (i18n) requirements to be unit tested.
In addition to my first liquibase post I give you some best practice in order to integrate liquibase in JUnit using hibernate JPA to ensure same datamodel during unit test and other stages. Use the power of mockito to setup your JUnit test class and inject your entity manager.
At this years JAX Andreas Günzel held a talk about code reviews. jaxenter just released an interview with Andreas (in German) to sum up some tipps and best practices.
In my current project we decided to use JBoss Drools 6, mainly for mapping data. It turned out to come in quite handy. However, when I tried to unit test my rules I was astonished how clumsy and cumbersome that was. Therefore I wrote a little library containing a JUnit-Runner that hides the needed boiler plate code and just lets you focus on the important thing: testing the rules.
Recently I used hazelcast in several projects. Especially in an Application Server environment using the hazelcast JCA connector it is pretty easy to use hazelcast with only a few lines of code. Unfortunately, Hazelcast.getAllHazelcastInstances() returns an empty set in unit tests. So, what we need to do is to mock our HazelcastFactory somehow.