Posts Tagged junit

About using Test Doubles in tests

I have just read an interesting chapter from the Software Engineering book at Google about using Test Doubles in tests.

The chapter discuss the various techniques of using test doubles in tests along with the pros and cons of using real implementations, fakes, stubbing with the support of mocking frameworks and interaction testing. It also refers to the benefits of running Contract Tests against the API’s public interface to catch contract changes prior to the production environment.

In my opinion, it is worth reading it to be aware of good practices when writing unit tests. Drop your comments here about what you think about it.

Tags: , , , , , , , , , ,

Jcombiner: Combinations of collections for Java

JCombiner is a framework to generate combinations of collections for Java. I have written it in Java 11 using Java 9 modules (JPMS) and Gradle as build tool. JUnit 5 and Mockito are used for unit testing and Jacoco for code coverage. Streams and the Collectors API are extensively used throughout the development of JCombiner project.

Jcombiner’s source code is available under GitHub.

Code examples of its usage can be found on GitHub here. More examples can be found on this module inside JCombiner.

Share your comments about this framework here! Please feel free to contribute to it, more features are welcome!

Tags: , , , , , , , , , , , , , , , ,

When to use TestNG or JUnit

There is an interesting discussion between using TestNG or JUnit on Java projects at Javalobby. It’s very worth reading.

Tags: , , , ,

Using Hamcrest and JUnit

Lately I started using the core Hamcrest matchers bundled with the JUnit framework to create more readable unit tests.

Hamcrest matchers were created to improve the readability of unit testing code. It’s a framework which facilitates the creation of matcher objects to match rules specified in unit tests. Some examples will let it to be clearer:

   1 import static org.hamcrest.CoreMatchers.equalTo;
   2 import static org.hamcrest.CoreMatchers.is;
   3 import static org.junit.Assert.assertThat;
   4 
   5 @Test
   6 public void shouldBeTheSamePerson()
   7 {
   8     Person me = new Person( "Rafael" );
   9     Person theOther = new Person( "Rafael" );
  10     assertThat( me, is( theOther ) );
  11 }
  12 
  13 @Test
  14 public void shouldHaveFixedSizeNumbers()
  15 {
  16     List<Integer> numbers = Arrays.asList( 1, 2, 3, 4, 5 );
  17     assertThat( numbers.size(), is( equalTo( 5 ) ) );
  18 }

The first example checks if one Person object is equal to another using the Object equals method, which was overridden in the Person class. The is syntax defines a matcher which is a shorthand to is(equalTo(value)). The second one uses the is(equalTo(value)) matcher to check the size of an integer list of fixed size numbers. The assertThat method is used in conjunction with the is(equalTo(value)) matcher, which makes the test sentence very human readable.

An interesting thing is the possibility to create a custom matcher, like this one which tests if a given list only has even numbers:

   1 public class AreEvenNumbers extends TypeSafeMatcher<Collection<Integer>> {
   2 
   3     @Override
   4     public boolean matchesSafely(Collection<Integer> numbers) {
   5         for (Integer number : numbers) {
   6             if (number % 2 != 0) {
   7                 return false;
   8             }
   9         }
  10         return true;
  11     }
  12 
  13     @Override
  14     public void describeTo(Description description) {
  15         description.appendText("even numbers");
  16     }
  17 
  18     @Factory
  19     public static <T> Matcher<Collection<Integer>> evenNumbers() {
  20         return new AreEvenNumbers();
  21     }
  22 }

And below are two tests which uses the AreEvenNumbers custom matcher:

   1 import static org.hamcrest.CoreMatchers.is;
   2 import static org.junit.Assert.assertThat;
   3 import static br.com.rafael.hamcrest.AreEvenNumbers.evenNumbers;
   4 
   5 @Test
   6 public void shouldHaveOnlyEvenNumbers()
   7 {
   8     List<Integer> numbers = Arrays.asList( 2, 4, 6, 8, 10 );
   9     assertThat( numbers, is( evenNumbers() ) );
  10 }
  11 
  12 @Test
  13 public void shouldNotHaveOddNumbers()
  14 {
  15     List<Integer> numbers = Arrays.asList( 1, 2, 4, 6, 8, 10 );
  16     assertThat( numbers, not( evenNumbers() ) );
  17 }

These two tests use the static factory method evenNumbers to instantiate the matcher on the test code. Not the use of the not matcher on the shouldNotHaveOddNumbers test to assert that no odd numbers are present on the given list. All tests use the static import feature, which turns the test not clean and not cluttered with the class qualification.

I haven’t experienced the other common matchers on unit testing code, like the Beans, Collections and Number ones. I think they turn the tests more readable, clean and easy to change. And you? Have you ever used Hamcrest matcher? If you have other examples of using it, post them here!

Updated: Static imports were added to the testing code.

Tags: , , , , , ,

Erich Gamma Discusses Jazz, Eclipse, JUnit and Design Patterns

Good interview from Erich Gamma at QCon London 2008, where he discusses, among other things, the JUnit framework, the Gang of Four book about Design Patterns and the Jazz project. I’ll try to summarize some of his interesting advices and responses here:

Why Eclipse is so successful:

“We focus on stable APIs, so we understood it was a commitment up front and we maintained our APIs, so we tried to really avoid breaking our community..”

About JUnit:

“We always said it would just be as simple as writing System.out.println() but fully automated….I think the key was it makes writing tests as simple as writing this debug statement….”

About Design Patterns:

“In Design Patterns we talked a lot about abstract coupling, that you can couple things by an abstract class, that the reference is only to an abstract class interface..”

“Never use the class names we give in the pattern for it – that’s wrong. Use the domain-specific names, make it very specific to what your use..”

He also gives advices in how to identify design patterns:

  • Something non-obvious
  • The same kind of structure
  • Confidence on multiple uses..

About Dependency Injection:

“I think it could be captured as a pattern. There are a lot of tradeoffs in there, it would fit into the whole creational realm..”

Check the whole presentation on InfoQ here. It’s worthwhile to see.

Tags: , , , ,