Mocking without the Hangover

Mocking without
the Hangover
Jan Wloka
jan.wloka@quatico.com
@crashtester

Small Engineering Shop in Zurich

Small Engineering Shop in Zurich
http://
jobs.quatico.com

We don’t like mocks
Mocking is fundamentally evil. It encourage you to write bad, poorly
factored code, not-very-functional code. It encourages you to avoid
standing up as much of your system as possible during integration testing.
Finally, all too often at the end of all that mocking all you end up with are some
really well tested Mocks nested N! levels. In other words, mocking produces
a bunch of useless code that costs money and time to maintain.
Mocking is Evil
— Eric Merritt { http://blog.ericbmerritt.com }
“
“”

They had written a series of tests for the business logic layer that completely
mocked out the data access layer. Normally this is ﬁne as you don’t want to
actually hit a database in a unit test, but what they had done was actually
mock out the majority of their business logic which meant the tests
were not doing anything useful at all.
All Your Mocks are Evil!!
— Stephen Haunts { https://stephenhaunts.com }
“
“”

If I could just mock out all of the EJB stuﬀ, I'd be sitting pretty. […]
Not even an hour had passed and I needed to mock
java.sql.Connection. 40 methods! Getters and setters for every parameter,
return value and counter for every method? .... hmmmm .... thinking this
through a little .... the reason we make the attributes private is for the
sake of encapsulation - to hide how things are done on the inside so that
we can change our business logic later without breaking a bunch of stuff that
decided to tap into our innards. But that doesn't really apply to a mock,
does it?
Evil Unit Testing
— Paul Wheaton { http://www.javaranch.com }
“
“”

I’ve never been a big fan of mocking frameworks, for one simple reason.
Simple stubbing relies on assumptions on the functioning of the mocked
part of your system that rarely match reality, for no one is going to look
at all the documentation of an API and decompile the code when writing a
one-line stub.
Mocking considered evil
— Sebastien Lambla { https://serialseb.com/blog/ }
“
“”

I’ve been there…
~10’000 Unit tests
~80% coverage
ø refactoring possible

Let’s talk!
about your experience

Why mocking?
Unit testing at scale

Key: Test in Isolation.
Simple: Arrange. Act. Assert.
@Test 
public void setPropertiesWithValidPropertiesYieldsSameObject()
throws Exception { 
Properties expected = new Properties(); 
 
Item testObj = new Item("/path").setProperties(expected); 
 
assertSame(expected, testObj.getProperties()); 
}

@Test
public void testGetImageLegendWithSourceAndCaptionReturnsBoth() throws Exception {
ResourceResolver resolver = new ResourceResolverImpl(client);
createPage(“/content/foobar”, new Properties(), PageType.PRESENCE.getTemplate());
createPage(“/content/foobar/ko”, new Properties(), PageType.LANGUAGE.getTemplate());
createPage(“/content/foobar/ko/home", new Properties(), PageType.HOME.getTemplate());
createPage(“/content/foobar/ko/home/content", new Properties(), PageType.DETAIL.getTemplate());
Resource contentPage = resolver.getResource(“/content/foobar/ko/home/content");
createResource(contentPage.getPath() + "/jcr:content/textimage", new Properties());
Resource target = resolver.getResource(contentPage.getPath() + "/jcr:content/textimage");
Properties imageProps = new Properties()
.append("source", "<sourceValue>")
.append("caption", "titleValue")
.append("sling:resourceType", ComponentType.IMAGE)
.append(JCR_LASTMODIFIED, new Time().format(DateFormat.GMT))
.append(JCR_LAST_MODIFIED_BY, "admin");
createResource(contentPage.getPath() + "/jcr:content/textimage/image", imageProps);
TextImageController testObj = new TextImageController().setup(createContext(target, contentPage));
assertEquals("titleValue<br /><sourceValue>", testObj.getImageLegend());
}

@Test
}
Arrange

@Test
}
Arrange
Act

@Test
}
Arrange
Act
Assert

Dependencies vs. Isolation
Sandbox
Test Object
{state, behavior}
Direct
Collaborator
{state, behavior}
Indirect
Collaborator
{state, behavior}
Parent
{state, behavior}
Data
{state}
Event
{state,
behavior}

Arrange: Dependencies?
• What: State, Behavior[, Event and Data]
• Where: Local, Parent, External
• How:
• Explicit/Implicit: Is it injectable?
• Direct/Indirect: Do I depend on it directly?
• Accessible/Inaccessible: Is it static, ﬁnal etc.?

Mockito 101
• Mock: Empty Object: No state, No behavior. 
 
ItemService service = mock(ItemService.class);
• Stub: Specify Behavior 
 
when(service.load(“index.html”)).thenReturn(“foobar”);
• Spy: Real Object: Real / partial state and behavior 
 
ItemService service = spy(new ItemService()); 
doReturn(“foobar”).when(service).load(“index.html”);

Partial Mocking
• Gradually mock behaviour
• mock(FooBar.class)
• mock(FooBar.class, CALLS_REAL_METHODS)
• spy(new FooBar())

Default Answers
public IProjectLink aProjectLink(String label, String linkType) {
IProjectLink result= mock(IProjectLink.class, RETURNS_SMART_NULLS);
when(result.getLabel()).thenReturn(label);
when(result.getLinkType()).thenReturn(linkType);
return result;
}
• Other default answers:
• CALLS_REAL_METHODS (partial mocking)
• RETURNS_MOCKS (mock return values)
• RETURNS_DEEP_STUBS (stub transitively)
• RETURNS_DEFAULTS (default answer)

Stub it in or out?
when(mock.methodCall(Matcher.anyString())).thenReturn(“value”);
when(mock.methodCall(Matcher.anyString())).then(new Answer() {});
when(mock.methodCall(Matcher.anyString())).thenThrow(Exception.class);
doReturn(“value”).when(mock).methodCall(Matcher.anyString());
doAnswer(new Answer() {}).when(mock).methodCall(Matcher.anyString());
doThrow(Exception.class).when(mock).methodCall(Matcher.anyString());
obj method argument matchers value / answer
obj method argument matchersvalue / answer

Danger: Partial Mocks
public String load(String path) throws FooException {
// ...
// method behavior
//...
return result;
}
doReturn().when() ——>
when().thenReturn() ——>
public class DbTest { 
@Mock 
private IPropertiesStore mockedStore; 
@InjectMocks 
private DB testObj; 
@Before 
public void setUp() throws Exception { 
testObj = DB.init(); 
MockitoAnnotations.initMocks(this); 
} 
InjectBehavior
InjectState

Assert: Effects?
• Assert genuine effects:
• Returned values. Changed state. Exceptions. 
 
assertEquals(), assertNotNull(),
@Test(expect = …)
• Mocks/spies verify behavior:
• Called methods. Count calls. Capture arguments.  
 
verify(mock,times(2)).methodFoo(Matchers.anyString())

Verify: calls w/ args
@Test
public void getContentShouldManageInputStreamsProperly() throws Exception {
InputStream inputStream= spy(new FileInputStream(new File("tmp/test.txt")));
Response testObj= spy(new Response(
HttpStatus.SC_OK,
Collections.emptyMap(),
inputStream));
testObj.getContent();
// way too many examples
verify(inputStream, times(2)).close();
verify(inputStream, atMost(2)).close();
verify(inputStream, timeout(100).atLeastOnce()).close();
verify(inputStream, never()).reset();
verify(testObj).getResponseHeader(anyString());
verify(testObj).getResponseHeader(eq(HttpUtil.CONTENT_TYPE));
}

Matchers make it fit
๏ org.mockito.Matchers, e.g.:
• any(Class<T>), anyBoolean()
• isA(Class<T>), eq(T), refEq(T, String…)
• isNull(Class<T>), notNull()
• same(T), contains(String)
• matches(String)
๏ Use org.hamcrest.Matchers with, e.g.:
• argThat(Matcher<T>)
• charThat(Matcher<Char>),
• booleanThat(Matcher<Boolean>)

Add unit tests
createItem(Item) : Item
getItem(String) : Item
updateItem(Item) : Item
ItemService
+ init() : DB
+ get(String) : Item
+ store(Item) : DB
+ delete(String) : DB
+ exists(Item) : boolean
- singleton : DB
DB
+ load(String) : Properties
+ save(String, Properties) : IPropertiesStore
+ remove(String) : IPropertiesStore
IPropertiesStore
+ load(String) : Properties
+ save(String, Properties) : IPropertiesStore
+ remove(String) : IPropertiesStore
- data : Map<String, Properties>
InMemoryPropertiesStore
datastorage
+ getPath() : String
+ getProperties() : Properties
+ setProperties(Properties) : Item
- path : String
Item
+ hasProperty(Object) : boolean
+setValue(Object, Object) : Properties
+ getValue(Object key) : Object
- data : Map<Object, Object>
Properties
properties

Get the Code.
https://github.com/jwloka/mocktesting/
git clone ssh://git@github.com/jwloka/mocktesting.git
Run it.
$ mvn clean install

Write valuable tests.
• Go through the code add unit tests
• Think about what to mock and why?
• Where to start? Follow the hints in the code!
• Remember: You are allowed to change the code!

Get the solution.
git checkout tags/v2

Mocks, revisited
• Can Mocking cause poorly factored code?
• Need for mocks: design feedback
• Be aware deeply nested mocks!
• Can Mocking break encapsulation?
• Mocked internal state
• Need for behavior veriﬁcation
• Can Mocking create artiﬁcial behavior?
• Mocks with state are dangerous
• Use stubs with canned values
• Can Mocking reduce test value?
• Mock direct collaborators only
• Under-specify with matchers

No Hangover, please!
Rules of the road:
• Try to use the real thing
• Mocks are for direct collaborators
• Never mock the test object
• Be aware of deeply-nested mocks, e.g.
RETURN_DEEP_STUBS
• Stateless mocks, with stubs to return
canned values
• Don’t verify on non public API
• Under-specify in mocks and stubs with
matchers.

Ready. Set. Go.
• Unit Testing In The Real World
• More guidance. More
examples.
• How to write unit tests?
• Measure test coverage.

Thank You.
jan.wloka@quatico.com
@crashtester

Mocking without the Hangover

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Dernier

Dernier (20)

Mocking without the Hangover