Nick Watts
 Senior Programmer/Analyst for OMIG
Technical Editor of NFJS, The Magazine
 Extension  of the No Fluff Just Stuff (NFJS)
  travelling symposium.
 Only NFJS speakers write articles for the
  magaz...
 Testing Education
 Getting Started in Unit Testing
 Mock Objects




         © Copyright, Ohio Mutual Insurance Group...
 Over  2 – 3 years we read articles about,
  attended user group meetings about,
  took a class as part of a Masters degr...
 Thearticle that finally made unit testing
 make sense to me:
 • Evolutionary architecture and emergent
   design: Test-d...
 Over  the 2 – 3 year learning period we also
  practiced writing unit tests.
 We started with the simplest possible JUn...
 Itwas absolutely necessary to
  understand the code in order to begin
  testing it.
 The newest member of the team has
...
 This was a v e r y l o n g process!
 Do not expect to get immediately
  satisfying results.
 Though some people presen...
 This all seems so obvious, why am I
 telling you?
  • It helps to hear that someone else went through
    the same exper...
 Real  code from a live production system
  that has been in place for over five years.
 Brief analysis of some of the c...
 Unit testing examples are often trite and
  too far off from reality.
 I believe you either are, were, or will be
  as ...
© Copyright, Ohio Mutual Insurance Group
                                           12
© Copyright, Ohio Mutual Insurance Group
                                           13
 Corebusiness domain package of a
 legacy JEE system (e-Quip’d™) atop a
 legacy COBOL policy management
 system (POINT IN...
 “I’mnot sure where to start because I
 can’t understand the code.”
  • Complexity
 “Idon’t want to write a test that us...
 “It’s
      too much of a hassle to write a test
  because of all the dependencies.”
  • Unruly Coupling
 “I’mnot suppo...
 This is “the ugly truth” in real code.
  Complexity abounds (both accidental
  and intentional).
 The complexity made t...
 Used   Old fashioned “elbow grease”.
 • Understood the business domain and the
   systems that support it.
 • Studied th...
© Copyright, Ohio Mutual Insurance Group
                                           19
© Copyright, Ohio Mutual Insurance Group
                                           20
Started simple: Chose the simplest
classes we could find. Usually POJOs and
Beans with little or no business logic.




  ...
public class OMIGSSNumberTest {
  public void test_default_constructor() {
     OMIGSSNumber ssn = new OMIGSSNumber();
   ...
 Atfirst, we also stumbled just writing
  some of the “simplest” tests.
 Putting static data into tests felt unnatural.
...
public void test_GetModifiedJulianDate() {
  OMIGDate od = new OMIGDate(2008, 8, 16);
  assertEquals(od.getModifiedJulianD...
More practice and learning. It just took
time to realize that it was acceptable to
build static test cases that didn’t tes...
public void test_trans_history_full_constructor() {
  TransactionHistoryRow row = new
       TransactionHistoryRow("01“,"2...
 Instantiating
            an object is unnecessarily
 complex because of coupling.
  • E.g. the BasicContract class cons...
 Testing   a method that connects to a
  database can be troublesome, but can be
  circumvented.
 A class that connects ...
You could repeatedly instantiate all of
the objects necessary to create the one
you’re really interested in testing.


Thi...
public void test_basic_contract() {
  ProductKey prodKey =
      new ProductKey("01", "20", "05", "OH", "CPP");
  PolicyKe...
 Our solution was to just mock the
 troublesome classes and ignore the setup
 of the object.
 • You eventually want to re...
public void test_basic_contract_best() {
  BasicContract bc = mock(BasicContract.class);
    assertNotNull(bc);
}




    ...
 We  took the easiest path by just mocking
  the class we wanted to test.
 Most of the object’s state is not needed,
  s...
 “mocks   do not implement any logic: They
 are empty shells that provide methods to
 let the tests control the behavior ...
 Mockito    is a mock object framework.
  • Gives you an object that looks like the real
    object, but may or may not, ...
We want to test this method in PolicyBase:


public void putOnHold() throws Exception {
  getBasicContract().setEndType("H...
public void test_put_on_hold__sans_mocking() throws
  Exception {
  ProductKey prodKey =
      new ProductKey("01", "20", ...
© Copyright, Ohio Mutual Insurance Group
                                           39
Without mocking, the test
                     won’t run because it
                     connects to a database.




© Cop...
The previous method is hard to test because
  of unruly coupling and the storeAppInfo()
  method, which connects to a data...
 Took  our time with unit testing as it was a
  big commitment.
 Started with small, easy unit tests.
 Increased our ab...
 nwatts@omig.com                     – work email



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

 Slides at:...
Upcoming SlideShare
Loading in …5
×

Unit Testing Case Study for COJUG - 05.11.2010

2,216 views

Published on

Nick Watts' "Unit Testing Case Study: How Ohio Mutual Insurance Group Got Started" presentation. Presented to the Columbus Java Users Group on May 11th, 2010 in Dublin, Ohio.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,216
On SlideShare
0
From Embeds
0
Number of Embeds
160
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Unit Testing Case Study for COJUG - 05.11.2010

  1. 1. Nick Watts Senior Programmer/Analyst for OMIG Technical Editor of NFJS, The Magazine
  2. 2.  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_subs cribe  @nfjsmag on Twitter. © Copyright, Ohio Mutual Insurance Group 2
  3. 3.  Testing Education  Getting Started in Unit Testing  Mock Objects © Copyright, Ohio Mutual Insurance Group 3
  4. 4.  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
  5. 5.  Thearticle 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
  6. 6.  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
  7. 7.  Itwas 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
  8. 8.  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
  9. 9.  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
  10. 10.  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
  11. 11.  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
  12. 12. © Copyright, Ohio Mutual Insurance Group 12
  13. 13. © Copyright, Ohio Mutual Insurance Group 13
  14. 14.  Corebusiness 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
  15. 15.  “I’mnot sure where to start because I can’t understand the code.” • Complexity  “Idon’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
  16. 16.  “It’s too much of a hassle to write a test because of all the dependencies.” • Unruly Coupling  “I’mnot supposed to write unit tests for methods that connect to a database.” • Unexpected Database Connections © Copyright, Ohio Mutual Insurance Group 16
  17. 17.  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
  18. 18.  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
  19. 19. © Copyright, Ohio Mutual Insurance Group 19
  20. 20. © Copyright, Ohio Mutual Insurance Group 20
  21. 21. 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
  22. 22. 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
  23. 23.  Atfirst, 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
  24. 24. public void test_GetModifiedJulianDate() { OMIGDate od = new OMIGDate(2008, 8, 16); assertEquals(od.getModifiedJulianDate(), 54694); } © Copyright, Ohio Mutual Insurance Group 24
  25. 25. 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
  26. 26. 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
  27. 27.  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
  28. 28.  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
  29. 29. 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
  30. 30. 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
  31. 31.  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
  32. 32. 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
  33. 33.  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
  34. 34.  “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
  35. 35.  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
  36. 36. We want to test this method in PolicyBase: public void putOnHold() throws Exception { getBasicContract().setEndType("HLD"); storeAppInfo(); } © Copyright, Ohio Mutual Insurance Group 37
  37. 37. 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
  38. 38. © Copyright, Ohio Mutual Insurance Group 39
  39. 39. Without mocking, the test won’t run because it connects to a database. © Copyright, Ohio Mutual Insurance Group 40
  40. 40. 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
  41. 41.  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 43
  42. 42.  nwatts@omig.com – work email  @nfjsmag – Twitter (for NFJS, The Magazine)  Slides at: http://www.slideshare.net/thewonggei/u nit-testing-case-study-cojug05112010 © Copyright, Ohio Mutual Insurance Group 44

×