JUnit & Mockito, first steps

Post on 15-Jan-2015

633 views 1 download

Tags:

description

JUnit & Mockito, first steps

Transcript of JUnit & Mockito, first steps

JUnit & Mockito,First steps

@QuadraticBEJul. 2014

So it’s done...

I’m Renato Primavera from Quadratic

I write software that helps customers to manage and make use of their geographical data

@RenatoPrimavera renato.primavera@quadratic.be

www.quadratic.be

Let’s start with

JUnit

JUnit is a programmer-oriented

testing framework for Java

It is a simple framework to write repeatable tests

JUnit is linked as a JAR at compile-time

The framework resides under package org.junit for JUnit 4 and later

<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.11</version> <scope>test</scope> </dependency>

... </dependencies>

in thePOM

It’s really simple to integrate JUnit in your Maven Project

If not using Maven,all you need is to add 2 JARs

on your test classpath

- junit.jar- hamcrest-core.jar

JUnit is based on Java annotations

@org.junit.Test@org.junit.BeforeClass@org.junit.Before@org.junit.AfterClass@org.junit.After

import org.junit.*; public class TestFoobar {

}

Let’s start a JUnit Test Case

@BeforeClasspublic static void setUpClass() throws Exception { // Code executed before the first test method } @Beforepublic void setUp() throws Exception { // Code executed before each test }

It’s possible to define some test context (called “Test Fixture”), before (“setUp”)...

@AfterClasspublic static void tearDownClass() throws Exception { // Code executed after the last test method }

@Afterpublic void tearDown() throws Exception { // Code executed after each test }

...and after (“tearDown”)...

@Testpublic void testOneThing() {

// Code that tests one thing}

@Testpublic void testAnotherThing() {

// Code that tests another thing}

Now you’re ready to write tests themselves

> Assertions (and Matchers…)

JUnit provides assertion methods for all primitive types and Objects and arrays

The parameter order is “expected value” followed by “actual value”

Optionally the first parameter can be a String message that is output on failure

import static org.junit.Assert.*;

assertEquals("failure - strings not equal", "text", "text");

assertFalse("failure - should be false", false);

assertSame("should be same", aNumber, aNumber);

assertArrayEquals("failure - byte arrays not same", expected,

actual);

There is a slightly different assertion, “assertThat” that

takes a Matcher object

import static org.junit.Assert.*;

import static org.junit.matchers.JUnitMatchers.*;

assertThat("albumen", both(containsString("a")).and

(containsString("b")));

assertThat(Arrays.asList("one", "two", "three"), hasItems

("one", "three"));

assertThat(Arrays.asList(new String[] { "fun", "ban", "net"

}), everyItem(containsString("n")));

Note that expected and actual are reversed compared to the

other assert methods...

assertThat can also be used with

Hamcrest MatchersHamcrest Provides a library of matcher objects (also known as constraints or predicates) allowing 'match' rules to be defined declaratively, to be used in other

frameworks

Hamcrest it is not a testing library: it just happens that matchers are very useful for testing

import static org.junit.Assert.*;

import static org.hamcrest.CoreMatchers.*;

assertThat("good", allOf(equalTo("good"), startsWith

("good")));

assertThat("good", anyOf(equalTo("bad"), equalTo("good")));

assertThat(7, not(CombinableMatcher.<Integer> either(equalTo

(3)).or(equalTo(4))));

assertThat(new Object(), not(sameInstance(new Object())));

> Test Suites(how to aggregate tests)

Using Suite as a runner allows you to manually build a suite containing tests from

many classes

To use it, annotate a class with @RunWith(Suite.class) and

@SuiteClasses(TestClass1.class, ...)

When you run this class, it will run all the tests in all the suite classes

import org.junit.runner.RunWith;

import org.junit.runners.Suite;

@RunWith(Suite.class)

@Suite.SuiteClasses({

TestFeatureLogin.class, TestFeatureLogout.class,

TestFeatureNavigate.class, TestFeatureUpdate.class

})

public class FeatureTestSuite {

// the class remains empty,

// used only as a holder for the above annotations

}

> Miscellaneous

Use JUnitCore to run tests and see the results on the console

> java org.junit.runner.JUnitCore TestClass1 [...other

test classes...]

Both your test class and junit must be on the classpath

If using Maven, just execute

> mvn test

...and the Surefire plugin of Maven will execute all JUnit tests under

src/test/java

The tests execution reportis then available in

target/surefire-reports

<?xml version="1.0" encoding="UTF-8" ?><testsuite failures="0" time="0.015" errors="0" skipped="0" tests="1" name="com.mycompany.app.AppTest"> <properties> ... </properties> <testcase time="0.002" classname="com.mycompany.app.AppTest" name="testApp"/></testsuite>

If for some reason, you don't want a test to fail, you just want

it ignored, you temporarily disable a test

@Ignore("Test is ignored as a demonstration")

@Test

public void testSane() {

assertThat(1, is(1));

}

Tests that 'runaway' or take too long, can be automatically failed

There are two options for implementing timeout

Timeout parameter on @Test Annotation (applies to test method)

@Test(timeout=1000)public void testWithTimeout() { ...}

#1

Timeout Rule (applies to entire test class)

public class HasGlobalTimeout { @Rule public Timeout globalTimeout = new Timeout(10000); // 10 seconds max per method tested @Test public void testInfiniteLoop{ … }}

#2

OK for JUnitLet’s see

now...

Mockito is a Java framework allowing the creation of

test double objects (mock objects) in automated

unit tests

Test Double is a generic term for any case where you replace a production object for testing purposes

Why mocking?

Some “real” objects required in Unit tests are really complex to instanciate and/or configure

Sometimes, only interfaces exist, implementations are not even coded

<dependencies> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-all</artifactId> <version>1.9.5</version> <scope>test</scope> </dependency>

... </dependencies>

in thePOM

It’s really simple to integrate Mockito in your Maven Project

Now we can verify interactions through mock objects

//Let's import Mockito statically so that the code looks clearer import static org.mockito.Mockito.*; //mock creation List mockedList = mock(List.class);

//using mock object mockedList.add("one"); mockedList.clear();

//verification verify(mockedList).add("one"); verify(mockedList).clear();

Once created, mock will remember all interactions

Then you can selectively verify whatever interaction you are

interested in

By default, for all methods that return value, mock returns null, an empty collection or appropriate primitive/primitive wrapper value

(e.g: 0, false, ...)

But wait!

This is where stubbing comes

//You can mock concrete classes, not only interfaces LinkedList mockedList = mock(LinkedList.class); //stubbing when(mockedList.get(0)).thenReturn("first"); when(mockedList.get(1)).thenThrow(new RuntimeException()); //following prints "first" System.out.println(mockedList.get(0)); //following throws runtime exception System.out.println(mockedList.get(1)); //following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999));

Mockito verifies argument values in natural java style: by using an equals() method

Sometimes, when extra flexibility is required then you might use

argument matchers

//stubbing using built-in anyInt() argument matcherwhen(mockedList.get(anyInt())).thenReturn("element");

//stubbing using hamcrest (let's say isValid() //returns your own hamcrest matcher):when(mockedList.contains(argThat(isValid()))).thenReturn("element");

//you can also verify using an argument matcherverify(mockedList).get(anyInt());

Here are some argument matchers

verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));//above is correct - eq() is also an argument matcher

verify(mock).someMethod(anyInt(), anyString(), "third argument");//above is incorrect - exception will be thrown because third argument is //given without an argument matcher

Note that if you are using argument matchers, all arguments have to be provided by matchers

Verifying exact number of invocations / at least x / never

//exact number of invocations verificationverify(mockedList, times(2)).add("twice");verify(mockedList, times(3)).add("three times"); //verification using never(). never() is an alias to times(0)verify(mockedList, never()).add("never happened"); //verification using atLeast()/atMost()verify(mockedList, atLeastOnce()).add("three times");verify(mockedList, atLeast(2)).add("five times");verify(mockedList, atMost(5)).add("three times");

Verification in orderSingle mock whose methods must be invoked in

a particular order

List singleMock = mock(List.class);

//using a single mocksingleMock.add("was added first");singleMock.add("was added second"); //create an inOrder verifier for a single mockInOrder inOrder = inOrder(singleMock); //following will make sure that add is first called with "was added first, //then with "was added second"inOrder.verify(singleMock).add("was added first");inOrder.verify(singleMock).add("was added second");

Verification in orderMultiple mocks that must be used in a particular order

List firstMock = mock(List.class);List secondMock = mock(List.class);

//using mocksfirstMock.add("was called first");secondMock.add("was called second");

//create inOrder object passing any mocks that need to be verified in orderInOrder inOrder = inOrder(firstMock, secondMock);

//following will make sure that firstMock was called before secondMockinOrder.verify(firstMock).add("was called first");inOrder.verify(secondMock).add("was called second");

Sometimes we need to stub with different return value/exception

for the same method call, we need to stub consecutive calls (iterator-

style stubbing)

when(mock.someMethod("some arg")) .thenThrow(new RuntimeException()) .thenReturn("foo"); //First call: throws runtime exception:mock.someMethod("some arg"); //Second call: prints "foo"System.out.println(mock.someMethod("some arg")); //Any consecutive call: prints "foo" as well (last stubbing wins).System.out.println(mock.someMethod("some arg"));

Alternative, shorter version of consecutive stubbing

when(mock.someMethod("some arg")) .thenReturn("one", "two", "three");

It’s also possible to create spies of real objects

When you use the spy then the real methods are called

(unless a method was stubbed)

List list = new LinkedList();List spy = spy(list);

//optionally, you can stub out some methods:when(spy.size()).thenReturn(100); //using the spy calls *real* methodsspy.add("one");spy.add("two"); //prints "one" - the first element of a listSystem.out.println(spy.get(0)); //size() method was stubbed - 100 is printedSystem.out.println(spy.size()); //optionally, you can verifyverify(spy).add("one");verify(spy).add("two");

So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction and their

effect on real instance state

The corollary is that when an unstubbed method is called on the spy but not on the real instance, you won't see any

effects on the real instance

To know when spying real objects!

Mockito does not delegate calls to the passed real instance, instead it actually creates a copy of it

Capturing arguments for further assertions with ArgumentCaptor

//create the ArgumentCaptor for class PersonArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);

//verify that the doSomething method of the mock object was called //with a Person argument verify(mock).doSomething(argument.capture());

//assert that the name of that Person argument was “John” Person person = argument.getValue();assertEquals("John", person.getName());

Thanks