Unit Testing Case Study: How Ohio Mutual Insurance Group Got Started

Nick Watts

Senior Programmer/Analyst for OMIG

Technical Editor of NFJS, The Magazine

NFJS, The Magazine

• Extension of the No Fluff Just Stuff (NFJS) travelling symposium.

• Only NFJS speakers write articles for the magazine.

• Delivered as PDF and ePub file downloads.

• www.nofluffjuststuff.com/home/magazine_subscribe

• @nfjsmag on Twitter.

© Copyright, Ohio Mutual Insurance Group 2

Agenda

• Testing Education

• Getting Started in Unit Testing

• Mock Objects

© Copyright, Ohio Mutual Insurance Group 3

Learn

• Over 2 – 3 years we read articles about, attended user group meetings about, took a class as part of a Masters degree about and attended conference sessions on testing.

• Bewilderment is an appropriate response for the first 6 – 12 months (or so).

© Copyright, Ohio Mutual Insurance Group 4

Learn

• The article that finally made unit testing make sense to me:

– Evolutionary architecture and emergent design: Test-driven design, Part 1 by Neal Ford.

• http://www.ibm.com/developerworks/java/library/j-eaed2/

© Copyright, Ohio Mutual Insurance Group 5

Practice

• Over the 2 – 3 year learning period we also practiced writing unit tests.

• We started with the simplest possible JUnit tests we could find to do.– Neal Ford asks the question, "What is the simplest

thing for which I can write a test?"

• Over time we were able to improve and write tests for increasingly trickier situations.

• Trying overly-complex tests was a common first misstep.

© Copyright, Ohio Mutual Insurance Group 6

Understand

• It was absolutely necessary to understand the code in order to begin testing it.

• The newest member of the team has been on for over 2 years.

© Copyright, Ohio Mutual Insurance Group 7

Learn, Practice and Understand

• This was a v e r y l o n g process!

• Do not expect to get immediately satisfying results.

• Though some people present it so, building a significant set of unit tests on an existing code base is not easy or quick.

© Copyright, Ohio Mutual Insurance Group 8

Reflect

• This all seems so obvious, why am I telling you?– It helps to hear that someone else went through

the same experience.

– Speakers and authors glaze over real details, such as “this is REALLY hard to do in REAL life”, to remain brief.

© Copyright, Ohio Mutual Insurance Group 9

The Case Study

• Real code from a live production system that has been in place for over five years.

• Brief analysis of some of the core business classes in the system.

• Brief description of major hurdles to writing tests against the code.

• Analysis of some methods for testing the code before refactoring it.

© Copyright, Ohio Mutual Insurance Group 10

Why A Case Study?

• Unit testing examples are often trite and too far off from reality.

• I believe you either are, were, or will be as confused as my team was when we began writing unit tests.

• I hope you’ll learn more by seeing real code than by seeing contrived examples.

© Copyright, Ohio Mutual Insurance Group 11

yDoc UML Diagram: Typical Example

© Copyright, Ohio Mutual Insurance Group 12

yDoc UML Diagram: More Realistic

© Copyright, Ohio Mutual Insurance Group 13

What is This Mess?

• Core business domain package of a legacy JEE system (e-Quip’d™) atop a legacy COBOL policy management system (POINT IN).– Roughly mirrors the logical view of a “policy” in

POINT IN.

– e-Quip’d™ was not built with unit testing in mind.

© Copyright, Ohio Mutual Insurance Group 14

What’s the Problem? Or, excuses for not unit testing

• “I’m not sure where to start because I can’t understand the code.”– Complexity

• “I don’t want to write a test that uses static data because it’s not a good test.”– Validity of Simple Tests

© Copyright, Ohio Mutual Insurance Group 15

What’s the Problem? Or, excuses for not unit testing

• “It’s too much of a hassle to write a test because of all the dependencies.”– Unruly Coupling

• “I’m not supposed to write unit tests for methods that connect to a database.”– Unexpected Database Connections

© Copyright, Ohio Mutual Insurance Group 16

Complexity

• This is “the ugly truth” in real code. Complexity abounds (both accidental and intentional).

• The complexity made the task of testing seem hopeless at first. We were unable to decide where to start because there is no clear entry point.

© Copyright, Ohio Mutual Insurance Group 17

How We Worked with the Complexity

• Used Old fashioned “elbow grease”.– Understood the business domain and the systems

that support it.

– Studied the code.

– Communicated with others who work on the system.

• A visualization is very helpful.– yDoc is an inexpensive way to start visualizing

your code in class-sized chunks.

© Copyright, Ohio Mutual Insurance Group 18

Basic Policy Class Hierarchy

© Copyright, Ohio Mutual Insurance Group 19

More Realistic Policy Class Hierarchy

© Copyright, Ohio Mutual Insurance Group 20

How We Worked with the Complexity

Started simple: Chose the simplest classes we could find. Usually POJOs and Beans with little or no business logic.

© Copyright, Ohio Mutual Insurance Group 21

Example of a Simple Test: OMIGSSNumber Class

public class OMIGSSNumberTest {

public void test_default_constructor() {

OMIGSSNumber ssn = new OMIGSSNumber();

assertNotNull(ssn);

assertNotNull(ssn.getSsNo());

assertEquals(ssn.getSsNo(), "");

}

}

© Copyright, Ohio Mutual Insurance Group 22

Validity of Simple Tests

• At first, we also stumbled just writing some of the “simplest” tests.

• Putting static data into tests felt unnatural.

• Tests with static data seemed invalid.

© Copyright, Ohio Mutual Insurance Group 23

Example of Simple Tests with Static Data

public void test_GetModifiedJulianDate() {

OMIGDate od = new OMIGDate(2008, 8, 16);

assertEquals(od.getModifiedJulianDate(), 54694);

}

© Copyright, Ohio Mutual Insurance Group 24

How We Worked with the Validity of Simple Tests

More practice and learning. It just took time to realize that it was acceptable to build static test cases that didn’t test all scenarios.

© Copyright, Ohio Mutual Insurance Group 25

Example of Simple Tests with Static Data

public void test_trans_history_full_constructor() {TransactionHistoryRow row = new

TransactionHistoryRow("01“,"21“,"05“,"CPQ“,"1234567“,"00“,"0888000“,"0888z“,"00“,3);

assertEquals("01", row.getLco());assertEquals("21", row.getMco());assertEquals("05", row.getPco());assertEquals("CPQ", row.getSymbol());assertEquals("1234567", row.getNumber());assertEquals("00", row.getMod());assertEquals("0888000", row.getAgencyId());assertEquals("0888z", row.getUserId());assertEquals("00", row.getProducerCode());assertEquals(3, row.getActivityCode());

}

© Copyright, Ohio Mutual Insurance Group 26

Unruly Coupling

• Instantiating an object is unnecessarily complex because of coupling.– E.g. the BasicContract class constructor requires a

PolicyKey reference be passed in, which requires that a ProductKey reference be passed in, which requires five Strings for its constructor.

– BasicContract is itself used in hundreds of classes.

© Copyright, Ohio Mutual Insurance Group 27

Unexpected Database Connections

• Testing a method that connects to a database can be troublesome, but can be circumvented.

• A class that connects to a database in a constructor is more than troublesome to test (i.e. you can’t just ignore a constructor).– E.g. PolicyBase

© Copyright, Ohio Mutual Insurance Group 28

How We Worked Around Unruly Coupling in Unit Tests

You could repeatedly instantiate all of the objects necessary to create the one you’re really interested in testing.

This code isn’t un-testable, it’s just a nuisance.

© Copyright, Ohio Mutual Insurance Group 29

How We Worked Around Unruly Coupling in Unit Tests

public void test_basic_contract() {

ProductKey prodKey =

new ProductKey("01", "20", "05", "OH", "CPP");

PolicyKey polKey = new PolicyKey(prodKey);

BasicContract bc = new BasicContract(polKey);

assertNotNull(bc);

}

What about testing classes that require a BasicContract reference to instantiate?

© Copyright, Ohio Mutual Insurance Group 30

How We Worked Around Unruly Coupling in Unit Tests

• Our solution was to just mock the troublesome classes and ignore the setup of the object.– You eventually want to refactor and remove the

unruly coupling. So start by pretending its not there by mocking.

© Copyright, Ohio Mutual Insurance Group 32

How We Worked Around Unruly Coupling in Unit Tests

public void test_basic_contract_best() {

BasicContract bc = mock(BasicContract.class);

assertNotNull(bc);

}

This is best because it is succinct, doesn’t require custom test code and the intent is very clear.

© Copyright, Ohio Mutual Insurance Group 33

“Mock it and forget it”

• We took the easiest path by just mocking the class we wanted to test.

• Most of the object’s state is not needed, so we don’t set it up.– Notice the deep knowledge of the classes involved

in this statement.

– Caution! Carefully consider an object’s internal state.

© Copyright, Ohio Mutual Insurance Group 34

Mock Objects

• “mocks do not implement any logic: They are empty shells that provide methods to let the tests control the behavior of all the business methods of the faked class. “– JUnit in Action, 2nd ed.

• Read about mock objects in JUnit in Action by Vincent Massol and Ted Husted and JUnit in Action, 2nd ed. by Tachiev et. al.

© Copyright, Ohio Mutual Insurance Group 35

Enter Mockito

• Mockito is a mock object framework.– Gives you an object that looks like the real object,

but may or may not, at you discretion, act like the real object.

– Has a very English-like syntax.

– Very good at working with “legacy” code.

– www.mockito.org

© Copyright, Ohio Mutual Insurance Group 36

Example of Common Mockito Usage in OMIG Code

We want to test this method in PolicyBase:

public void putOnHold() throws Exception {

getBasicContract().setEndType("HLD");

storeAppInfo();

}

© Copyright, Ohio Mutual Insurance Group 37

An Attempt at Testing putOnHold() Without Mocking

public void test_put_on_hold__sans_mocking() throws Exception {

ProductKey prodKey =

new ProductKey("01", "20", "06", "RI", "CPP");

Policy policy = new Policy(prodKey);

assertTrue(StringUtils.isBlank(

policy.getBasicContract().getEndType()));

policy.putOnHold();

assertTrue(policy.isOnHold());

} © Copyright, Ohio Mutual Insurance Group 38

Basic Policy Class Hierarchy

© Copyright, Ohio Mutual Insurance Group 39

An Attempt at Testing putOnHold() Without Mocking

© Copyright, Ohio Mutual Insurance Group 40

Without mocking, the test won’t run because it connects to a database.

Example of Common Mockito Usage in OMIG Code

The previous method is hard to test because of unruly coupling and the storeAppInfo() method, which connects to a database. The solution…

public void test_put_on_hold() throws Exception {Policy policy = mock(Policy.class);when(policy.getBasicContract()).

thenCallRealMethod();when(policy.isOnHold()).thenCallRealMethod();doCallRealMethod().when(policy).putOnHold();…

}

© Copyright, Ohio Mutual Insurance Group 41

Summary

• Took our time with unit testing as it was a big commitment.

• Started with small, easy unit tests.

• Increased our abilities with learning and practice – over time.

• Used mock objects to solve our biggest problems.

© Copyright, Ohio Mutual Insurance Group 42

Contacting Me

• nwatts@omig.com – work email

• @nfjsmag – Twitter (for NFJS, The Magazine)

• Slides at: http://www.slideshare.net/thewonggei/unit-testing-case-study-cojug05112010

© Copyright, Ohio Mutual Insurance Group 43