Unit testing basic

Unit testing

(basic)
November 2011

What is Unit Testing

Unit test is a method by which individual units of source code
are tested to determine if they are fit for use.
A unit is the smallest testable part of an application like
method or class.

Unit tests are written from a programmer’s perspective.
They ensures that a particular method of a class successfully
performs a set of operations.

Unit testing drives design: developer is concerned about how
client will use the interface of the class that is under the test.

What is not for?
It's not for testing correct inter-operation of multiple
subsystems.
NOTE: It should be a stand-alone test which is not related
to other subsystems.

It should not rely on external resources like(RDBMS,LDAP etc).
NOTE: Introducing dependencies on external resources or
data turns unit tests into integration tests.

In many cases you can't write a unit test to reproduce bug
appeared in production.
NOTE: it's not regression testing. with unit test you can
check logic responsible for interaction between different
layers.

The advantages of Unit Testing
● Ensure code continues to work as intended(only if it has a
good coverage)

● Safe refactoring. Allows refactoring without fear to break the
code.

● Fewer bugs. Find some tricky bugs in logic on first stage
NOTE: tricky unit test scenarios may prevent many bugs.

● Developer concentrates more on the code and design.
NOTE: less build/deploy cycles to see some progress.
green bar shows you the progress

● Documentation

Disadvantages of Unit testing
Big time investment. For the simple case you lose about 20%
of the actual implementation, but for complicated cases you lose
much more.
NOTE: If you correctly follow TDD it will going to save you
time later in long-term perspective!

Design Impacts. Sometimes the high-level design is not clear
at the start and evolves as you go along - this will force you to
completely redo your test which will generate a big time lose.
NOTE: postpone unit tests in this case until you have
clarified high-level design.

Best Practices
● Make sure your tests test one thing and one thing only.
● Readability is important for tests. (see Example)
● Each unit test should be independent from the other.
● Separate you concerns. Extract layers to improve the
design. (see Example with DAO layer)
● Mock behavior with mocks to concentrate on test
scenario.
● Test Coverage(Check coverage during testing)
● Tests should run automatically to provide continuous
feedback.
Keep the bar green to keep the code clean!

Bad practices
● A singleton gets implemented using a static method. Static
methods are avoided by people who do unit testing
because they cannot be mocked or stubbed.
Static methods are death to unit testability ref

● Don't rely on external resources

● Do not test the GUI.

JUnit - Adding new test case
Mark your test cases with @Test annotations.

Use @Before and @After to run method before and after
every test case. Several tests need similar objects created
before they can run. (See Example)

Use @BeforeClass and @AfterClass to run for one time
before and after all test cases.(Use it only to share expensive
setup)

Static imports makes code more readable: (See Example)
import static org.mockito.Mockito.*;
import static org.junit.Assert.*;

@RunWith(MockitoJUnitRunner.class)

JUnit test structure
Make test readable. Use next pattern:

// Given
Create some objects required for testing.

// When
Execute method that is under test

// Then
Check state and verify interaction

See example

JUnit - Assertion
1. Choose correct assert method from org.junit.Assert.*:
assertNull, assertNotNull, assertTrue, assertEquals...

2. Keep it simple:
assertEquals(age, calculateAge(dob)); // bad practice
assertEquals(age, 25); // Best practice. Keep it simple

3. Use overloaded method with argument for message:
assertNull("Value must be null in case of error", value);

JUnit - test under construction
Sometimes we need to temporarily disable a test that is
under construction. Use @Ignore annotation on method
or class to achieve it. Specify the reason why it's ignored.

@Ignore("Enable when TASK-2 is implemented")
public class MyClassTest {
@Test public void testThat1() { ... }
@Test public void testThat2() { ... }
}

public class MyClassTest {
@Ignore("Gotta go now! will fix it later.")
@Test void testThat1() { ... }
}

JUnit - Test Case With Exception
1. Expect that exception is thrown: (See example) @Test
(expected=EmailExistException.class) public void
testExceptionIsThrown() { ... }
2. More flexible old school way:
try { // execute method under the test customerService.add
(customer);
fail("exception must be thrown");
} catch (ServiceException exception) {
// state assertion: check error code
assertEquals(exception.getCode(), 404);
}
3. JUnit 4.7 has @Rule ExpectedException

State vs Interaction testing
State testing asserts properties on an object
Example: Verify that after tested method execution object has
properties: assertEquals(2, item.getCount());

Interaction testing verifies the interactions between objects.
Example: Did my controller correctly call my services in
specified order? Can be used only with mocked objects.

Mockito is a framework for interactions testing.

Mockito is a mocking framework
that tastes really good!

Mock behavior with mocks.
Mocks or mock objects simulate the behavior of complex, real
(non-mock) objects and are therefore useful when a real object
is impractical or impossible to incorporate into a unit test.

They provide:
● Default values unless stubbed
● Can help verify interactions, order of interaction, method
parameters etc.

Mockito is a Java based mocking framework that allows you to
write beautiful tests with clean & simple API.

Why Mockito is good?

● with Mockito, you only stub what you need and go on
happily completing the functionality. No need to stub
everything.

● simple and clean syntax

● all required documentation can be found in javadocs to org.
mockito.Mockito.

● Has an ability to create partial mocks.

● It tastes really good

JUnit - Mock in Mockito
This will mock all methods in MyService class and provide
default values:

1. @Mock MyService myService;
All classes with @Mock annotation will be injected to
@InjectMocks class by type automatically when using
@RunWith(MockitoJUnitRunner.class).

2. You can mock and inject services manually:
MyService myService = mock(MyService.class);
ServiceUnderTest service = new ServiceUnderTest();
service.setMyService(myService);
You can mock concrete classes, not only interfaces!

JUnit - Stubbing in Mockito
Stubbing is adding canned response to Mock object methods.

Examples:
● method stubbing:
when(mockService.someMethod(”value”))
.thenReturn(”someValue”);
● stubbing method with exception:
when(mockService.someMethod("value"))
.thenThrow(new MyException("Error"));
or stubbing void method with exception:
doThrow(new MyException(”Error”)
.when(mockService).someMethod("value");

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

JUnit - Argument matching in Mockito

Sometimes, when extra flexibility is required then you might
use argument matchers:
● when(mockedList.get(anyString())).thenReturn("element");
● any(ClassName.class)
● Custom argument matcher:(see ArgumentMatcher)

IMPORTANT: If you are using argument matchers, all
arguments have to be provided:
verify(mock).someMethod(anyInt(), anyString(), eq("arg"));
verify(mock).someMethod(anyInt(), anyString(), "arg") -
Wrong

JUnit - Verify behavior in Mockito
Once created, mock will remember all interactions. Then you
can selectively verify whatever interaction you are interested in:

● verify(mockService).someMethod("someArgs");
● verify(mockService, times(2)).someMethod("someArgs");
● verify(mockService, never()).someMethod("someArgs");
NOTE: never() is an alias to times(0)
● atLeastOnce()
● atLeast(2)
● atMost(5)
● verifyZeroInteractions(mockService)
● verifyNoMoreInteractions(mockService)

JUnit - Verification in order
Verification in order is flexible - you don't have to verify all
interactions one-by-one but only those that you are
interested in testing in order.

//create inOrder object passing any mocks relevent for in-order verification
InOrder inOrder = inOrder(firstMock, secondMock);

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

JUnit - Spy(Partial mocking) in Mockito
When you use the Spy then the real methods are called (unless
a method was stubbed).
● Calls real methods unless the method is stubbed.
● Use of too much spy is potential code smell.

MyService myService = new MyService();
MyService spy = spy(myService);
//optionally, you can stub out some methods when(spy.
someMethod()).thenReturn(val);
//real method logic will be executed
spy.realMethod();

See Example

Test Coverage (see Example)
Eclemma plugin for eclipse: http://www.eclemma.org/

#ant coverage - to generate report from console

Test Driven Development

After that build project, deploy, make sure that it works.
See Example

Unit testing is a lot like going to the gym

Let's drink!

Contact Information
Email: yuri.anischenko@gmail.com

Unit testing basic

More Related Content

What's hot

Viewers also liked

Similar to Unit testing basic

Recently uploaded

Unit testing basic