Not your father's tests

@oldJavaGuy@ZalandoTech
Not your father’s tests
Advanced Testing Patterns in Java (and Scala)

Sean P. Floyd
• Full Stack Engineer @ Zalando
• ~20 years experience
• Java, Maven, Spring, Scala,
Groovy
• StackOverﬂow: bit.ly/spfOnSO

Agenda
• Software Design Principles (applied to tests)
• JUnit best practices
• Matchers
• Mocks
• Extending the Lifecycle
• Testing in Scala
• Testing the Untestable

Software Design
Principles
(and their application in tests)

THE SOLID Principles
• Single Responsibility Principle
• Open / Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversions Principle
• Michael Feathers, Uncle Bob Martin, ~2003

Single Responsibility Principle
• Mapping production to test:
• 3 levels of production code (class, method, input)
• JUnit: 2 levels of test (class, method)
• Only one type of change should break any given test
A class should have only a single responsibility (i.e. only one potential
change in the software's speciﬁcation should be able to affect the
speciﬁcation of the class)

class StringUtils{ // dimension 1
// dimension 2
static String leftPad(String s, char c, int n){
if(s==null) return s; // dimension 3 a
if(n <= s.length()) return s; // dimension 3 b
StringBuilder sb = new StringBuilder(n);
for(int i = s.length(); i < n; i++){
sb.append(c);
}
// dimension 3 c
return sb.append(s).toString();
}

public class BadStringUtilsTest {
/* violates single responsibility
principle */
@Test public void badLeftPadTest() {
assertNull(leftPad(null, ' ', 10));
assertEquals("foo", leftPad("foo", ' ', 3));
assertEquals("foo", leftPad("foo", ' ', 4));
}
}

Open / Closed Principle
• Closed for modiﬁcation applies to tests also
• Antipattern: Subclasses for Tests
• Antipattern: package protected access
• Better: Clean abstractions, mock objects
“Software entities should be open for extension, but
closed for modiﬁcation”

class TightlyCoupledClass{
private final MyService ms = new MyServiceImpl();
public String foo(){ return ms.bar(); }
}
class TightlyCoupledClassTest{
@Test public void fooTest(){
TightlyCoupledClass t = new TCC(){
@Override public String foo(){
return "baz";
} };
assertEquals("baz", t.foo());
}
}

final class NotSoTightlyCoupledClass{
public NSTCC(MyService ms){this.ms = ms;}
private final MyService ms;
public String foo(){ return ms.bar(); }
}
class NotSoTightlyCoupledClassTest{
@Test public void fooTest(){
MyService ms = Mockito.mock(MyService.class);
NotSoTightlyCoupledClass n = new NSTCC(ms);
when(ms.bar()).thenReturn("baz");
assertEquals("baz", n.foo());
}
}

Liskov Substitution Principle
• When designing class hierarchies, design
corresponding test class hierarchies
• If the classes have a common contract, the same is
true for the test classes
“Objects in a program should be replaceable with instances of
their subtypes without altering the correctness of that program.”

abstract class AbstractCollectionTest{
protected abstract <T> Collection<T> create();
@Test public void equalsTest(){
assertEquals(create(), create());
}
// etc.
}
class ArrayListTest extends AbstractCollectionTest{
protected <T> Collection<T> create(){
return new ArrayList<>();
}}
class HashSetTest extends AbstractCollectionTest{
protected <T> Collection<T> create(){
return new HashSet<>();
}}}

Interface Segregation Principle
• If a class implements multiple interfaces, test them
separately
“Many client-speciﬁc interfaces are better than one
general-purpose interface.”

class Multi implements Fooable, Barable {
@Override public String foo() { return "foo"; }
@Override public String bar() { return "bar"; }
}
class FooableMultiTest extends AbstractFooableTest {
@Override protected Fooable create() {
return new Multi();
}
}
class BarableMultiTest extends AbstractBarableTest {
@Override protected Barable create(){
return new Multi();
}
}

Dependency Inversion Principle
• Test public methods, not implementation details
• Test on the same level of abstraction as the
implementation
• Don’t change or test internal state
“Depend upon Abstractions. Do not depend upon
concretions.”

class WayTooInvolvedArrayListTest {
@Test
public void testAdd() throws Exception {
List<String> l = new ArrayList<>();
l.add("foo");
Field f = ArrayList.class
.getDeclaredField("elementData");
Object[] arr = (Object[]) f.get(l);
assertEquals("foo", arr[0]);
}
}

JUnit 4.x 
Best Practices

Assertions vs
Matchers

public class TestWithStandardAssertions {
private List<String> list;
@Test
public void exactlyOneNoneEmptyString() {
assertNotNull(list);
assertEquals(list.size(), 1);
assertNotEquals(list.get(0).trim(), "");
}
}
Plain JUnit assertions

java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
list = Arrays.asList();
java.lang.AssertionError:
Expected :0
Actual :1
list = Arrays.asList(" ");
java.lang.AssertionError: Values should be
different. Actual:
Output from plain assertions

Hamcrest
• “Matchers that can be combined to create ﬂexible
expressions of intent”
• Make tests (and failure output) readable
• Work on the correct abstraction level
• Built-in matchers, extendable with custom
matchers

public class TestWithHamcrestMatchers {
@Test
public void exactlyOneNoneEmptyString() {
assertThat(list, hasSize(1));
assertThat(list, hasItem(nonEmptyString()));
}
}

// custom Matcher
private Matcher<String> nonEmptyString() {
return new TypeSafeMatcher<String>() {
boolean matchesSafely(String s) {
return !s.trim().isEmpty(); }
void describeTo(Description d) {
d.appendText(
"a non-empty String"); }
};
}

// Error messages for Hamcrest Matchers:
Expected: a collection with size <1>
but: was null
list = Arrays.asList();
Expected: a collection with size <1>
but: collection size was <0>
list = Arrays.asList(" ");
Expected: a collection containing a non-empty
String but: was " "

Dependency Inversion
Principle revisited
• Abstraction in its main sense is a conceptual
process by which general rules and concepts are
derived from the usage and classification of
specific examples, literal ("real" or "concrete")
signifiers, first principles, or other methods. 
Source: en.wikipedia.org/wiki/Abstraction
• The hard part is finding the right level of abstraction

Abstraction level: too low
• “Stringly typed”:
• Method parameters that
take strings when other
more appropriate types
should be used.
• Message passing without
using typed messages etc.
• Tests will most likely have to
parse custom Strings, tightly
coupling them to domain
knowledge
blog.codinghorror.com/new-programming-jargon/

Abstraction level: too high
• “Baklava Code”:
• While thin layers are ﬁne for a
pastry, thin software layers
don’t add much value,
especially when you have
many such layers piled on
each other. Each layer has to
be pushed onto your mental
stack as you dive into the
code.
• Tests will most likely have to
either set up or mock multiple
layers, introducing tight coupling
blog.codinghorror.com/new-programming-jargon/

Example: JSON
• JSON (JavaScript Object Notation) is becoming the
lingua franca for Web-based (Restful?) APIs
• Almost every application deals with JSON in one
form or another
• How can we test JSON output for correctness?

public class ManualJsonTest {
private String json = "{ "id": 123, "name": "John Smith"}";
@Test
public void exactMatch() {
// missing a space breaks the assertion, although the semantics
// are still correct
assertEquals(json, "{"id": 123, "name": "John Smith"}");
}
}
Bad: Manual JSON assertions
False negatives through irrelevant things like
whitespace or property ordering

public class RegexJsonTest {
@Test
public void regexMatch() {
// too technical, we have to effectively implement a JSON parser
// which violates the single responsibility principle
// also, re-ordering of properties is semantically correct
// but breaks the test
assertTrue(json.matches(
"{s*"id"s*:s*123s*,s*"name"s*:s*"John Smith"}"));
}
}
Bad: Regex JSON assertions
False negatives through property reordering or
grammar edge cases

public class JacksonJsonTest {
@Test
public void jacksonMatch() throws IOException {
// better: we no longer have to implement our own parsing
JsonNode jsonNode = new ObjectMapper().readTree(json);
assertTrue(jsonNode.isObject());
// but this is still more complicated than necessary:
assertEquals(jsonNode.get("id").asInt(),123);
assertEquals(jsonNode.get("name").asText(),"John Smith");
}
}
Better: Using Jackson
Still: much boilerplate
Non-descriptive error messages

JsonPath-assert
A library with hamcrest-matchers for JsonPath.
https://github.com/jayway/JsonPath/tree/master/json-path-assert

public class JaywayJsonTest {
String json = "{ "id": 123, "name": "John Smith"}";
@Test
public void jsonPathMatch() throws IOException {
JsonAssert.with(json)
.assertEquals("id", 123)
.assertEquals("name", "John Smith");
}
}
Perfect: Using JsonAssert
No boilerplate, automatic type conversion,
descriptive error messages

Matchers (summary)
• Look for existing matcher libraries
• Write your own matchers in a re-usable way
• start with a local factory method
• if you need it in another class, move it to a dedicated helper
class (e.g. XyzMatchers)
• if you need it in multiple projects, make your own matcher library

Mocking
mock: verb (gerund or present participle: mocking)
1. tease or laugh at in a scornful or contemptuous manner
2. make (something) seem laughably unreal or impossible
3. make a replica or imitation of something.
pragprog.com/magazines/2010-05/the-virtues-of-mockery

No, really
• A mock object is a testing tool that acts as a stand-in for a
“real” object during testing in much the same way as an Elvis
impersonator stands in for the real King. The impersonator is
cheaper, easier to access, and most likely lighter weight. 
pragprog.com/magazines/2010-05/the-virtues-of-mockery
• Mocking in Java can take take numerous forms:
• overriding methods of the original class
• providing an alternative interface implementation
• creating a proxy (interface based or cglib etc.)

Recalling SOLID
• overriding methods of the original class
• violates Open / Closed principle
• providing an alternative interface implementation
• violates Interface segregation principle
• creating a proxy (interface based or cglib etc.)
• violates Dependency Inversion Principle

Mockito
http://mockito.org/

public interface UserService {
Optional<Session> login(
String user, String pass);
}
interface Session{ /* stuff in here */ }
public class LoginService {
private final UserService us;
public boolean login(String user, String pass){
return us.login(user, pass).isPresent();
}
}

public class LoginServiceTestWithoutMockito {
@Test
public void loginSuccess() {
LoginService ls = new LoginService(
(user, password) -> Optional.of(new Session() {}));
assertTrue(ls.login("ali baba", "open sesame"));
}
@Test
public void loginFailure() {
LoginService ls = new LoginService((user, password) -> Optional.empty());
assertFalse(ls.login("ali baba", "open sesame"));
}
}
Mocking without Mockito
• if interface evolves, all tests break
• code duplication, no common setup

public class LoginServiceTestWithMockito {
UserService userService; LoginService ls;
@Before public void setUp(){
userService= mock(UserService.class);
ls = new LoginService(userService);
}
@Test public void loginSuccess() {
when(userService.login(anyString(), anyString()))
.thenReturn(Optional.of(mock(Session.class)));
assertTrue(ls.login("ali baba", "open sesame"));
verify(ls,times(1)).login("ali baba", "open sesame"));
}
}
Mocking with Mockito
• Common setup
• No tight coupling to UserService and Session
• Verify mock interaction (reduce false positives)

Advanced Mockito
• All methods in a mock return default values (null for
references, 0 or false for primitives)
• Use Mockito.spy(object) to wrap an existing object
inside a mock
• Use .thenAnswer() to interact with method
parameters rather than return static values
• Use deep stubs to return chained mocks (huge
code smell, but useful for legacy code)

Mocking Web APIs
• Scenario: Testing API clients
• Blackbox:
• Faking the API calls by a 3rd party Mock Server
• MockServer, WireMock
• Whitebox:
• Using the API’s own code to create the Mock
• Example: Spring MockMvc
• No actual network call, mock requests / responses

new MockServerClient("127.0.0.1", 1080)
.when(
request()
.withMethod("POST").withPath("/login")
.withQueryStringParameters(new Parameter("returnUrl", "/account"))
.withBody(exact("{username: 'foo', password: 'bar'}")),
exactly(1)
)
.respond(
response()
.withStatusCode(401)
.withHeaders(
new Header("Content-Type", "application/json; charset=utf-8"),
new Header("Cache-Control", "public, max-age=86400")
)
.withBody("{ message: 'incorrect username and password combination' }")
);
Example: MockServer
• set up behavior to mimic real API
• start up server via @Before method or @Rule

Spring Mvc Controller
@RestController @RequestMapping("/contacts")
public class ContactController {
private final ContactRepository contactRepository;
public ContactController(ContactRepository contactRepository) {
this.contactRepository = contactRepository;
}
@RequestMapping(method = GET, value = "/{contactId}")
public Contact getContact(@PathVariable int contactId) {
return contactRepository.findOne(contactId);
}
}

public class ContactControllerTest {
ContactRepository contactRepository; MockMvc mockMvc;
@Before public void setup() {
contactRepository = mock(ContactRepository.class);
ContactController controller = new ContactController(contactRepository);
mockMvc = MockMvcBuilders.standaloneSetup(controller).build();
}
@Test public void getContactById() throws Exception {
final Contact contact = new Contact();
contact.setFirstName("Jim");
when(contactRepository.findOne(anyInt())).thenReturn(contact);
mockMvc.perform(get("/contacts/123").accept(APPLICATION_JSON)) //
.andExpect(status().isOk()) //
.andExpect(content().contentType(APPLICATION_JSON)) //
.andExpect(jsonPath("$.firstName").value("Jim"));
}
}
MockMvc
• Request / response cycle is virtual
• Integrates nicely with Mockito and JsonPath

JUnit lifecycle
Runners, rules, annotations

Basic Lifecycle
• @Before / @After
• instance, before / after every test
• setting up / cleaning up test data
• instantiating classes and mocks
• @BeforeClass / @AfterClass
• static, before / after entire test class
• bootstrapping databases and web servers
• creating and deleting temporary folders

Okay, but
• What if I need the same kind of setup in many
tests?
• Move the setup to an abstract test class
• If setup needs test-speciﬁc parameters, get them
from abstract methods

Inheritance vs aggregation
• This works ﬁne for test hierarchies with a clear relation
(“AbstractUserServiceTest” -> “UserServiceLoginTest”)
• LSP says: common hierarchies for production and tests
• Which means: we probably shouldn’t have an
AbstractDBIntegrationTest, since we probably don’t
have an AbstractDatabaseService
• Okay, so how can we embrace DRY without
inheritance?

Custom JUnit Runners
• @RunWith(someclass) replaces JUnit’s standard Runner
• Full control over entire lifecycle
http://www.rockcellarmagazine.com/2012/10/01/the-man-behind-darth-vader/

Example Runners
• SpringJunit4Runner
• Ties JUnit lifecycle to Spring lifecycle
• Dependency injection, transaction handling
• MockitoRunner
• Mocks all ﬁelds annotated with @Mock
• Parameterized
• Runs tests with parameters

@RunWith(Parameterized.class)
public class FibonacciTest {
@Parameters public static Collection<Object[]> data() {
return Arrays.asList(new Object[][] {
{ 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 },
{ 4, 3 }, { 5, 5 }, { 6, 8 }
});
}
@Parameter(0) public int fInput;
@Parameter(1) public int fExpected;
@Test public void test() {
assertEquals(fExpected, Fibonacci.compute(fInput));
}
}
Parameterized Example
• Generates one test per method, per values array
• Values are common for all test methods

• You can’t mix runners (e.g. Spring + Mockito)
• Runner interface is very technical
• You have to do everything
http://www.quickmeme.com/meme/35n2io
Runner Drawbacks

JUnit Rules
Reusable JUnit lifecycle
components

public static class HasTempFolder {
@Rule
public TemporaryFolder folder = new TemporaryFolder();
@Test
public void testUsingTempFolder() throws IOException {
File createdFile = folder.newFile("myfile.txt");
File createdFolder = folder.newFolder("subfolder");
// ...
}
}
Example test rule
• Rules can interact with test lifecycle
• @Rule is per test, @ClassRule is per test class

public class NTimes implements TestRule {
private final int times; private final Logger logger;
public NTimes(final int times, final Logger logger) {
this.times = times; this.logger = logger; }
@Override public Statement apply(Statement base, Description desc) {
return new Statement() {
@Override public void evaluate() throws Throwable {
StopWatch stopWatch = new StopWatch();
for (int i = 0; i < times; i++) { base.evaluate();}
logger.info("Executed {} times in {} ms", times,
stopWatch.getLastTaskTimeMillis());
}};
}}
Implementing our own rule
• runs every test n times, logs total duration

Lifecycle recap
• Use @Before / @After for speciﬁc local setup
• Use @Rule / @ClassRule if you want to reuse setup
logic, ideally move your rules to libraries
• Use custom runners for parameterized testing or
Spring (but you can’t combine them)
• You probably shouldn’t write a custom runner

Testing in Scala
https://www.youtube.com/watch?v=RnqAXuLZlaE

Scala Test frameworks
• ScalaTest
• supports a plethora of testing styles
• very readable DSLs
• custom matcher SPI
• alternative: Spec2

class ExampleSpec extends FlatSpec with Matchers {
"A Stack" should "pop values in last-in-first-out order" in {
val stack = new Stack[Int]
stack.push(1)
stack.push(2)
stack.pop() should be (2)
stack.pop() should be (1)
}
it should "throw NoSuchElementException if an empty stack is popped" in {
val emptyStack = new Stack[Int]
a [NoSuchElementException] should be thrownBy {
emptyStack.pop()
}
}
}
Example from ScalaTest

Differences
• Java:
• tests are defined through annotated methods, instantiated through
reflection
• 2 levels of nesting (class, method)
• Scala:
• tests are defined programmatically, using a DSL
• no isolation: runtime error in one test destroys everything
• arbitrary levels of nesting
• many different ways to write tests

class TestWithArbitraryDepth extends FunSpec{
describe("my package"){
describe("my class"){
describe("my method"){
it("should reject nulls"){
intercept[NullPointerException] {
myClass.myMethod(null)
}
}
it("should return true for non-null params"){
assert(myClass.myMethod("foo"))
}
}
}
}
}
Arbitrary nesting in ScalaTest

TestWithArbitraryDepth:
my package
my class
my method
- should reject nulls
- should return true for non-null params
- should return false for input 42 * FAILED
Output

Matchers
• Extend your test class with the Matchers trait
• Matchers enable “readable” assertions with the
“should” keyword, e.g. 
 
result should have length 3 
file should have ('name ("temp.txt"))
• You can create custom matchers and combine
them using a DSL

trait CustomMatchers {
class ExtensionMatcher(expected: String)
extends Matcher[java.io.File] {
def apply(left: java.io.File) = {
val name = left.getName
MatchResult(
name.endsWith(expected),
s"""File $name did not end with extension "$expected"""",
s"""File $name ended with extension "$expected""""
)
}
}
def hasExtension(extension: String) = new ExtensionMatcher(extension)
}
Custom matcher

Property-based testing with
ScalaCheck
• ScalaCheck is a tool for testing Scala and Java
programs, based on property specifications and
automatic test data generation.
• Define a property that specifies the behaviour of a
method or some unit of code, and ScalaCheck
checks that the property holds.
• All test data are generated automatically in a
random fashion, so you don't have to worry about
any missed cases.

class Fraction(n: Int, d: Int) {
require(d != 0)
require(d != Integer.MIN_VALUE)
require(n != Integer.MIN_VALUE)
val numer = if (d < 0) -1 * n else n
val denom = d.abs
override def toString = numer + " / " + denom
}
Class to test

class PropertySpec extends FlatSpec with PropertyChecks
with Matchers {
forAll { (n: Int, d: Int) =>
whenever(d != 0 && d != Integer.MIN_VALUE
&& n != Integer.MIN_VALUE) {
val f = new Fraction(n, d)
if (n < 0 && d < 0 || n > 0 && d > 0)
f.numer should be > 0
else if (n != 0) f.numer should be < 0
else f.numer should be === 0
f.denom should be > 0
}
}
Property Testing (Part1)

val invalidCombos =
Table(
("n", "d"),
(Integer.MIN_VALUE, Integer.MIN_VALUE),
(1, Integer.MIN_VALUE),
(Integer.MIN_VALUE, 1),
(Integer.MIN_VALUE, 0),
(1, 0)
)
forAll(invalidCombos) { (n: Int, d: Int) =>
evaluating {
new Fraction(n, d)
} should produce[IllegalArgumentException]
}
}
Property Testing (Part2)
Source: http://stackoverﬂow.com/a/30152387/342852

JUnit ScalaTest
Use Hamcrest Matchers Mix in Matchers Trait
@Before, @After Do it in code
@Rule Mix in a trait
Parameterized runner Property Testing with ScalaCheck
Solving similar problems in
JUnit and ScalaTest

What now?
• Java and Scala can be combined
• You can write tests for your Java code in Scala
• No runtime dependencies to Scala
• Scala can be integrated easily into all major build
systems and IDEs

OK but what if I really don’t
like Scala?
• JUnit 4 is also kinda cool when you use Hamcrest,
Mockito and Rules
• JUnit 5 will come soon, supporting lots of new cool
features:
• New test callback mechanism
• Dynamic test generation (limited)
• Lambda support

Testing the Untestable
https://mubi.com/ﬁlms/mission-impossible

Untestable Software
checklist
• Shared static state
• Lack of Visibility
• Deep dependency tree

Case Study
Stripes Framework
used by Zalando Shop
in the early years

The madness
• Stripes relies on static initialization in a Servlet Filter
• Controllers, Localization and many other
components depend on this state
• Spring integration is worse: 
 
ContextLoader 
.getCurrentWebApplicationContext() 
.getBean(MyBean.class)

Divide and conquer
• Create solutions for Stripes and Spring, separately
• Make sure you tear up everything you set up
• Keep low-tech hacks in one place
• Provide high level facades for your tests

static StripesFilter stripesFilter;
static MockServletContext ctx;
public static void initStripes() throws Exception {
if (!stripesIsAlreadyActive()) {
stripesFilter = new StripesFilter();
final MockFilterConfig config = new MockFilterConfig();
config.addInitParameter("ActionResolver.Packages", "de.zalando.shop.frontend.stripes.action");
ctx = new MockServletContext(); config.setServletContext(ctx);
stripesFilter.init(config);
}
}
public static void shutdownStripes() throws Exception {
if (stripesFilter != null) {
stripesFilter.destroy(); stripesFilter = null; ctx = null; }
}
private static boolean stripesIsAlreadyActive() {
final Logger stripesLogger = Logger.getLogger(StripesFilter.class);
final Level oldLevel = stripesLogger.getLevel();
stripesLogger.setLevel(Level.FATAL);
try { new LocalizableMessage("link.catalog") .getMessage(Locale.GERMAN);
return true; } catch (final Exception e) { return false; }
finally { stripesLogger.setLevel(oldLevel); }
}
StripesTestUtils (extract)

private static ConfigurableWebApplicationContext ctx;
public static void registerBean(Object service, String beanName) {
getOrCreateTestWebAppContext().getBeanFactory().registerSingleton(beanName, service); }
private static ConfigurableWebApplicationContext setupContextLoaderTestWebApplicationContext() {
try { ConfigurableWebApplicationContext cwa = new GenericWebApplicationContext();
AutowiredAnnotationBeanPostProcessor autowiredAnnotationBeanPostProcessor =
new AutowiredAnnotationBeanPostProcessor();
autowiredAnnotationBeanPostProcessor.setBeanFactory(cwa.getBeanFactory());
cwa.getBeanFactory().addBeanPostProcessor(autowiredAnnotationBeanPostProcessor);
getCurrentContextField().set(null, cwa); ctx = cwa; return cwa;
} catch (Exception e) { fail(e.getMessage()); throw new IllegalStateException(); } }
private static Field getCurrentContextField() throws NoSuchFieldException {
final Field contextField = ContextLoader.class.getDeclaredField("currentContext");
contextField.setAccessible(true); return contextField; }
private static ConfigurableWebApplicationContext getOrCreateTestWebAppContext() {
WebApplicationContext currentWebApplicationContext = ContextLoader.getCurrentWebApplicationContext();
ConfigurableWebApplicationContext twa;
if ((currentWebApplicationContext instanceof ConfigurableWebApplicationContext)
&& (currentWebApplicationContext == ctx)) {
twa = (ConfigurableWebApplicationContext) currentWebApplicationContext;
} else { twa = setupContextLoaderTestWebApplicationContext(); }
return twa; }
SpringTestUtils (extract)

Visibility
• If you control the sources, change
visibility to package-protected
• If you don’t, use reﬂection and build
high-level facades

Case study
ANTLR (ANother Tool for
Language Recognition) is a
powerful parser generator
for reading, processing, or
translating structured ﬁles.

How to unit test a grammar?
• Grammars consist of rules
• Let’s try to test rules separately
• Each rule is a dedicated method in the parser, and it’s
protected, so we have to hack it
• Let’s use convention over configuration to generate
test from sample files
• We’ll use the file naming convention <rule>.txt and
create test dynamically with ScalaTest

describe("Valid examples for") {
baseDir.listFiles().foreach({
(f) => {
val ruleName: String = f.getName.replace(".txt", "")
describe(ruleName) {
try { val method: Method = parserType.getDeclaredMethod(ruleName)
describe("should be successfully parsed") {
val source: String = new String(Files.readAllBytes(f.toPath), UTF_8)
val index = new AtomicInteger();
source.split("---+").map(stripComments).foreach((src) => {
val ct: Int = index.getAndIncrement()
it("item[" + ct + "]") {
val parser: P = parserFor(src, ruleName)
try { method.invoke(parser) } catch {
case e: InvocationTargetException
=> fail(s"$ruleName[${ct}]", e.getCause)
} } }) }
} catch {
case e: NoSuchMethodException => {
err.println(s"Bad rule name: $ruleName")
} } } } }) }
Generating tests dynamically

Deep Dependency Tree

Law of Demeter
• the Law of Demeter for functions
requires that a method m of an
object O may only invoke the
methods of the following kinds of
objects:
• O itself
• m's parameters
• Any objects created / instantiated
within m
• O's direct component objects
• A global variable, accessible by
O, in the scope of m
https://commons.wikimedia.org/wiki/File:Demeter_Altemps_Inv8596.jpg

Testing tightly coupled code
if (articleDetailLayout.getArticleMedia() != null
&& articleDetailLayout.getArticleMedia().getThreeSixty() != null
&& articleDetailLayout.getArticleMedia().getThreeSixty()
.getImage().getMediumUrl() != null) {
articleContainer.setProduct360DegreeView(
articleDetailLayout.getArticleMedia().getThreeSixty()
.getImage().getMediumUrl());
}
• Use Mockito’s deep stubbing technique
@Test public void deepStubbing() {
ArticleDetailLayout articleDetailLayout =
mock(ArticleDetailLayout.class, RETURNS_DEEP_STUBS);
String url = "http://mysite.com/myImage.jpg";
when(articleDetailLayout.getArticleMedia().getThreeSixty().getImage()
.getMediumUrl()).thenReturn(url);
assertThat(articleDetailLayout.getArticleMedia().getThreeSixty()
.getImage().getMediumUrl(), is(url));}

Source: http://www.gapingvoidart.com/gallery/any-questions/

JOIN OUR TEAM!
github.com/zalando
@ZalandoTech
tech.zalando.com/jobs

Not your father's tests

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Not your father's tests

Similar to Not your father's tests (20)

Recently uploaded

Recently uploaded (20)

Not your father's tests