Law of Demeter and Unit Test Setup

Originally published 30 Nov 2007

Have you ever seen or even developed a long, complex setup method in JUnit?  Maybe it was because the production code was violating the Law of Demeter.  Here's another Robert Martin Craftsman style blog.

Apprentice:  Journeyman, I'm having trouble writing the fixtures for my JUnit tests.  They take too long.  I spend about 10 times longer writing tests than the production code.
Journeyman:  Really?  Unit test expert Gerard Meszaros says that tests should take only 10% to 20% of development time.
Apprentice:  Well, I'm experiencing the exact opposite.
Journeyman:  Let me take a look.
Apprentice:  Sure.
Author Note:  This is a trivial example for this blog entry.  I've seen some really obscure test setup methods.  The example is based on the sequence diagram chapter in Martin Fowler's UML Distilled book.

 public class OrderTest {
 
     private Order order;
 
     @Before
     public void setUp() throws Exception {
         Product product1 = new Product(11.00);
         OrderLine line1 = new OrderLine(2, product1);
         
         Product product2 = new Product(22.00);
         OrderLine line2 = new OrderLine(3, product2);
 
         OrderLine[] lines = new OrderLine[] {line1, line2};
         order = new Order(Arrays.asList(lines));
     }
     
     
     @Test
     public void priceShouldBe88() {
         assertEquals(88.00, order.getPrice());
     }
 }
  

Journeyman:  Okay, can I see the Order.getPrice() method?

     public double getPrice() {
         double price = 0.00;
         
         for (OrderLine orderLine : orderLines) {
             Product product = orderLine.getProduct();
             double productPrice = product.getPrice();
             int quantity = orderLine.getQuantity();
             price += productPrice * quantity;
         }
         
         return price;
     }
 

Journeyman:  Ah, I see the issue.  Have you ever heard of the Law of Demeter (LoD)?
Apprentice:  Huh?
Journeyman:  The LoD has a few different names and related principles, but basically it means that an object should only deal with and only with its collaborators.
Apprentice:  Huh?
Journeyman: You see how Order iterates through its OrderLine objects?
Apprentice:  Yeah.
Journeyman:  Well, that's fine.  But then you grab the Product and then grab its price.  You've violated the LoD.  Order should only know about OrderLines.  You've got more of a procedural design here, where you reach down into all the objects in the graph, grabbing all the data you need, and then do your thing.  A more object oriented design would be to distribute the work.  Do a little bit of work and delegate the rest to collaborating objects.
Apprentice:  Oh, I think I'm beginning to see.
Journeyman:  You should go read up on Craig Larman's GRASP principles.  He calls the LoD Don't Talk to Strangers.
Apprentice:  Okay, will do.
Journeyman:  Have you been following test driven development (TDD)?
Apprentice:  Uh..., well..., not really.  But I do write the tests afterwards.
Journeyman:  Complex test fixtures jump right out at you when you're doing TDD.  You realize something is wrong right away.  In fact, many times your testing style changes into more of an interaction based style.  But I'm getting ahead of myself.  Let's refactor this together.
Apprentice:  Okay, cool, pair programming.
Journeyman:  Right.  Remember, Order should only deal with OrderLines.
Now, the setUp() method looks like:

     @Before
     public void setUp() throws Exception {
         OrderLine line1 = stubOrderLineGetPriceToReturn(22.00);
         OrderLine line2 = stubOrderLineGetPriceToReturn(66.00);
 
         OrderLine[] lines = new OrderLine[] {line1, line2};
         order = new Order(Arrays.asList(lines));
     }
 

And the Order.getPrice() method looks like:

     public double getPrice() {
         double price = 0.00;
         
         for (OrderLine orderLine : orderLines) {
             price += orderLine.getPrice();
         }
         
         return price;
     }
 

Apprentice:  Okay, now I really see.  Order and its test are simpler, but don't we have the same amount of work anyway?  We had to write OrderLine.getPrice() and test that.
Journeyman:  Yes.  The work is distributed.  But I prefer lots of simpler objects with simpler test specifications than more complex objects and tests.
Apprentice:  What do you mean, more objects?  We didn't create any new objects.
Journeyman:  I meant generally speaking, not necessarily in this case.  Like I said, do a little work and pass the buck.  That might mean creating Data Clumps, aggregate objects for collections, objects that represent abstract data types, and so on, but again, I'm getting ahead of myself.
Apprentice:  Should I always follow the LoD?
Journeyman:  Well, there are of course consequences.  Classes tend to have larger APIs because sometimes they need to wrap the functionality of collaborating objects.  And you need to step through more objects to understand an algorithm as a whole because it's distributed.  But most of the time, I follow LoD because dependencies are reduced.
Apprentice:  All right, I'll give it a shot.  Thanks.

The Difference Between a Property, Field, Attribute

Originally published 3 Aug 2007

I’ve been asked a similar question at least three times this year.  It goes something like, “What’s the difference between a field and a property?”  Or, “Is there a difference between an attribute and a property?”  Given that many inexperienced developers automatically generate getters and setters for all their fields, I can understand the confusion.

I always give them the example of a circle.  Here’s some Groovy code:

class Circle {
   def radius
   
   def getDiameter() {
      2 * radius
   }
   
   getArea() {
      Math.PI * Math.pow(radius, 2)
   }
   
   def getCircumference() {
      2 * radius * Math.PI
   }
}

radius is a field, also known as an instance variable, also known as a member variable in C++.  It’s an implementation detail of the Circle, i.e., it’s a private variable that gets stored as part of the Circle object.

Properties are more public aspects of an object.  In Java, following JavaBeans conventions for getters and setters allows you to expose properties.  Those properties don’t have to be backed up by fields, but in many cases are.

Coming back to the Groovy Circle, what are its properties?  We’ll you get radius for free as a read-write property.  But because we’ve got some getters that compute other values based on radius, we also have diameter, area, and circumference properties.  These happen to be read-only properties since we didn’t provide setters, but we could have (which would update the radius field accordingly).  You can dump all of a Circle object’s properties in Groovy like this:

println myCircle.properties

The point is Circle could be implemented in different ways: by using a diameter field instead of radius, for instance, but it would have the same properties.

Now, let’s talk about attributes.  I typically think of UML when I hear attributes.  Here’s UML for Circle:

Notice that I’ve distinguished the derived diameter, area, and circumference attributes with a “/”.  This is standard UML.  radius is a regular, non-derived attribute.  We can distinguish fields from other computed properties like this.  However, because we’re modeling, and thinking in a higher level of abstraction, I like to think of attributes as more synonymous with properties.  I’d rather not make the assumption that every attribute is implemented with a field.

A similar discussion of these terms can be found here.

How to Refactor Many Arguments

Originally published 25 May 2007

The following conversation is based on a true story.  The roles are taken from Robert Martin’s Craftsman series.

Apprentice:  Hey, can I ask you something?
Journeyman:  Sure.
Apprentice:  I was looking at a big constructor on one of our domain objects and I saw some groupings and was wondering whether it would be good to create objects for those groupings.  Is there some kind of pattern for that?
Journeyman:  Well first, how many parameters are there?
Apprentice:  72.
Journeyman:  72!?  Wow.  Talk about a code smell .  PMD's ExcessiveParameterList rule will flip out on this one.  I guess the author mapped those parameters straight from the out-of-our-control XML schema, whose document instances get unmarshalled in order to create the object.  We don’t have to follow suit and create such a flat domain model that matches the schema.
Apprentice:  What do you mean?
Journeyman:  Well, what I really mean is that I'd much prefer distributing the logic among some richer objects.  That is, create more little objects with little methods that do a little of the work.  Not one big object that does it all.  There would be an impedance mismatch between XML and the domain model, but that’s typical because of the technology differences.  I suppose the only benefit of the big constructor approach is the simpler mapping... maybe, but the negatives are much too great.
Apprentice:  What are the negatives?
Journeyman:  Well, for one, trying to list all 72 parameters in the correct order would be a pain.  And trying to understand the object as a whole with all those fields would be difficult.  Here [grabbing his Refactoring book].  You were initially asking about the “Introduce Parameter Object” refactoring.  Read that refactoring.  It can probably give you better details.
Apprentice:  Martin Fowler.  Does he know what he’s talking about?
Journeyman:  Oh yeah.  He’s one of the Masters.  Let’s take a look at the class.  [Brings up the class in the IDE]

public ImportantDomainObject(
   ...
   int x, int y,
   ...
   double min, double max,
   ...)

Well, I can see a few data clumps already.  You see the x and y?
Apprentice:  Yeah.
Journeyman:  That’s probably a Point.  Also, that min and max, that looks like a Range.  What I would do is search for data clumps like these and create objects for them.  Then, see where they’re used in ImportantDomainObject and start moving behavior into the new objects.  Distribute the logic.  We can create a richer domain model this way.  You’ll probably find clumps of these clumps and can follow the same process.
Apprentice:  Okay.  This sounds great.  Thanks.  I’m on it.
Journeyman:  Thank you for recognizing this and taking the initiative to improve the code base.

DBC Precondition/Postcondition Subclass Rules

Originally published 12 Apr 2007

I was recently in a discussion regarding the precondition and postcondition covariance and contravariance rules of design by contract (DBC) in an inheritance/implementation hierarchy. In order to obey the Liskov substitution principle (LSP) , a subclass or interface implementation can only meet or:

• Weaken the preconditions of the base class, not strengthen them (contravariance).
• Strengthen the postconditions of the base class, not weaken them (covariance).

There was some confusion as to why this was the case. So I came up with an analogy to explain. If you think in terms of the client requesting services of an object specifying the preconditions and postconditions, it all makes sense.

So the analogy? Have you ever had to request a help desk ticket? Maybe you need administrative rights or something. And you hope that a specific someone is assigned to that ticket because she's really good and can get the job done quickly and accurately. Let's use that as an example.

The general IT support group contract is:

• Precondition: Submit a help desk ticket filling in all the forms on the web site.
• Postcondition: We'll get back to you within two hours.

Now, suppose Suzy Support works in the IT support group. She's really good and efficient. You can think of her as a subclass of the IT support group base class. In the past, whenever I've had a problem and I just happened, purely by chance, to pass her in the hallway and mention it to her, she could solve it in minutes. From my perspective, as a client of the IT support group, that's acceptable.

Suzy's contract is:

• Precondition: Just tell me the problem. You don't have to fill out a help desk ticket for me. This is weaker than the IT support group's precondition because I have less work to do.
• Postcondition: I'll solve it in minutes. This is a stronger postcondition. I get better response time.

Make sense?

By the way, for all the IT support group managers out there, this is just an analogy. I know bypassing the help desk ticketing system messes up metrics.

Collection Utility Methods on the Object

Originally published 16 Apr 2006

I’ve been experimenting lately with a technique that I’m still unsure about. It has a little smell to it, but it has some benefits. The technique is to add static collection-related utility methods on an object. That is, I’ll add a static method that takes a collection of that object on the object itself.

Take the classic Shape example:

   public class Shape {
      // here’s a typical instance method
      public void draw();

      // here's what I’m talking about.
      public static void draw(Collection shapes) {
         for (Iterator it = shapes.iterator(); it.hasNext; ) {
            Shape shape = (Shape) it.next();
            shape.draw();
         }
      }
   }

Now, I haven’t done this kind of thing much; maybe once or twice. The first time I did it was because I noticed some duplication. The exact looping code was shared by multiple clients. I wanted to remove the duplication, but I didn’t know where to put it, so I stuck it on the object itself. The clients became (in the context of this example):

   someShapeClientMethod() {
      Shape.draw(myShapes);
      ...
   }

I think this actually improves clarity (although I could have accomplished the same thing by creating a helper draw() method in the client). This also has the benefit of grouping the iteration logic close to its source, e.g.,Shape here.

The real world example where I first used this was a query.  I had a collection of objects and I wanted to find a specific one. Say, I had a collection of Shapes and I wanted to know who was the biggest:

public static Shape getBiggest(Collection shapes);

I think this technique is most applicable under the following circumstances:

1. For good reason, multiple clients share the code and you want to remove the duplication.
2. The number of such utility methods is very small. Otherwise, it would be better to group the methods in another, separate utility class (e.g., Shapes or ShapeUtils).

What bothers me most is that I can’t recall seeing this technique used anywhere. That could mean that there’s something really bad about it. One problem is that it clutters the object with additional methods. That’s why I think it should be used judiciously. Also, from a purist view, do these methods really belong on the object?

What do you think?

A Common Set of Test Refactorings

Originally published  19 Feb 2006

Today, I want to blog about what I think might be my most common set of low level Eclipse refactorings used together when I’m developing unit tests. I use this set to parameterize tests as discussed in Tabular Tests. Lately, I’ve been trying to use the Eclipse refactorings as much as possible, thinking that the automation would be less likely to break things than if I made the changes manually. It’s also interesting to make code changes without doing any typing. The set consists of:

1. Extract Local Variable (possibly multiple times).
2. Extract Method
3. Inline the local variables created in step 1.

So let’s suppose I’m about to start work on a new method. I like to start with a brain dump of most, if not all of the test cases. This is to get me thinking about the desired behavior and also because it clears my head, so that when I start writing the code, I can focus. Once I’m ready, I start with a simple case.

Let’s take the Range.equals() example from the previous blog. My brain dump would have resulted in a table like this:

Min	Max	Equals?
same	same	true
different	same	false
same	different	false

Yes, I would have jotted down other, exceptional cases for things like null and a non-Range object, but that’s out of scope here. For this blog, I’m just concentrated on comparing Range objects. I start with the positive case and come up with something like:

   private static final int MIN = 1;
   private static final int MAX = 7;

   private Range range = new Range(MIN, MAX);

   public void testEqualsAnotherRange() {
      Range anotherRange = new Range(MIN, MAX);
      assertEquals(range, anotherRange);
   }


To be honest, I probably would have had the MIN and MAX constants hardcoded in there, but at some point, I would have performed Extract Constant to come up with the above.

After I get that test to pass (by returning true), I’m ready to write the next test. I want to pick something simple again (of course in this example they’re all simple). But before I write the next test, I do something that is probably considered cheating by the hardcore test-driven development crowd. I’m not too concerned because I know from experience that I’m going to end up with tabular tests. In fact, the table is specified above!  So here goes the set of refactorings:

I first Extract Local Variable on MIN and MAX:

   public void testEqualsAnotherRange() {
      int testMin = MIN;
      int testMax = MAX;
      Range anotherRange = new Range(testMin, testMax);
      assertEquals(range, anotherRange);
   }


Now I know from my table that I need a boolean for my expected equals. There's no simple Eclipse refactoring so I manually make the change:


   public void testEqualsAnotherRange() {
      int testMin = MIN;
      int testMax = MAX;
      boolean expectedEquals = true;
      Range anotherRange = new Range(testMin, testMax);
      assertEquals(expectedEquals, range.equals(anotherRange));
   }


I highlight the last two lines and perform Extract Method:

   public void testEqualsAnotherRange() {
       int testMin = MIN;
       int testMax = MAX;
       boolean expectedEquals = true;
       testEqualsAnotherRange(testMin, testMax, expectedEquals);
   }

   private void testEqualsAnotherRange(int testMin, int testMax,
           boolean expectedEquals) {
       Range anotherRange = new Range(testMin, testMax);
       assertEquals(expectedEquals, range.equals(anotherRange));
   }


I want to get back to what it looks like in the table, so I Inline each local variable:

   public void testEqualsAnotherRange() {
      testEqualsAnotherRange(MIN, MAX, true);
   }

   private void testEqualsAnotherRange(int testMin, int testMax,
         boolean expectedEquals) {
      Range anotherRange = new Range(testMin, testMax);
      assertEquals(expectedEquals, range.equals(anotherRange));
   }


I just created the first row of the table by applying the set of refactorings that is the topic of this blog. At this point, I usually look at the parameterized method and make sure I’m happy with the signature. I’ve already done most of this when I extracted the method, but Eclipse doesn’t let me make the method static, if that’s appropriate (in this case it’s not). Eclipse also lists all the checked exceptions, which for tests, I’d rather generalize to Exception.  This doesn't apply in this case either.

During this set of refactorings, I would have ran the tests after a change or two just to make sure I didn’t break anything. I also do that because it feels good to get that green bar.

This is a pretty trivial example. Most of the time much more is going on in the parameterized method, but this still shows the removal of duplication.

I could have made these changes manually, but like I mentioned above, I like the automation; I’m less likely to break things.

Okay, I can write the next test now:

   public void testEqualsAnotherRange() {
      testEqualsAnotherRange(MIN,     MAX, true);
      testEqualsAnotherRange(MIN - 1, MAX, false);
   }

I’ve got the red bar. Time to make it green.

TDD Pattern: Tabular Tests

Originally published  5 Feb 2006

Today, I thought I'd blog about one of my most common testing patterns.  I call it table-like tests because I end up with a test method that calls a helper, parameterized test method.  The high level test method shows all the test cases in what looks kind of like a table.  To give proper credit to this technique, I believe I read about it on www.junit.org or one of the XP sites years ago, but I couldn't find the article with a quick Google search.  To demonstrate, suppose I were working on a Range class and was currently focused on the equals() method.  I'd end up with the following:

   private static final int MIN = 1;
   private static final int MAX = 7;

   private Range range = new Range(MIN, MAX);

   public void testEqualsAnotherRange() {
      testEqualsAnotherRange(MIN,     MAX, true);
      testEqualsAnotherRange(MIN - 1, MAX, false);
      testEqualsAnotherRange(MIN,     MAX + 1, false);   }

   private void testEqualsAnotherRange(int testMin,
         int testMax, boolean expectedEquals) {
      ...
   }

Now, I know there are other tests for the equals() method, but I'm focusing on the meat of the tests here.  I also want to emphasize that I don't start out specifying all the tests like this.  I actually write one of the test cases, get that test to pass by minimally implementing the Range class, and then, as I start to write the next test case, I see the pattern and will extract the method and parameterize it for the next test case.
Time to make some points:

1. Test cases for the equals() method are grouped together.  If I want to know how the equals() method works for non-exceptional cases, all the test cases are right there. When I write code, I focus on a method for a particular production class.  That is, I'm trying to build out all the functionality for that method before moving on to the next method (or class).  I find it helpful to have all the test cases grouped together.  Parameterizing tests keeps the test cases as close together as possible.
2. Whenever I detect duplication, I strive to remove it.  This is a way to do so among the test cases.
3. The mapping between test methods and production class methods is nearly one to one.  There's one main testEquals() method for one equals() method.  Of course, I'll have test methods for exceptional cases, but I don't have much more test methods than production methods.  If I kept each test case in its own method, I'd have a harder time removing duplication and I would have much more test code than production code.

I should also point out that many times, I don't use the same fixture.  In the example above, I did, but many times I don't.  The parameters passed in to the test helper method could be used to setup the production object.  Sometimes, the parameters are used to help mock a nested object.   Take, for example, the typical web site Order class.  Let's suppose I were focused on the getTotal() method:

   private Order order = new Order();

   public void testGetTotal() {
      assertEquals(0.00, order.getTotal(), 0.0001);
      testGetTotal(1, 3.00, 3.00);
      testGetTotal(3, 5.00, 18.00);
      // etc.
   }

   private void testGetTotal(int lineItemQuantity,
         double lineItemPrice, double expectedTotal) {
      // create a line item
      // add line item to order
      // verify total
   }


Now, I should point out some of the concerns of using this technique:

1. It doesn't follow the JUnit convention of working with the same fixture per TestCase.  Many times, my "fixture" is just an empty production object that will be setup in individual test methods.  Behaviour Driven Development (BDD) is getting press these days and its focus is on fixtures called Contexts.  Caveat: my knowledge of BDD is from reading this one article by Dave Astels, and I haven't experimented with it.  It seems to be good for showing behavior in a given context, whereas my technique is method focused.  Maybe I'll give it a shot in the future.
2. Because there isn't a real fixture, the test methods are more static than object-oriented.  That is, I might not be working with instance variables of the TestCase.  I don't find this to be an issue though.  I thought I'd point it out for OO purists.
3. Gerard Meszaros, who is writing a good book on test automation patterns, pointed out that if one of my earlier tests fails, then later tests won't be run.  He also pointed out that it is harder to determine how many total test cases there are since some are embedded.  These are valid points.  To counter, I mentioned that I am following test-driven development, so I am building the tests as I go, and I usually don't run into the situation where an earlier test fails, although it does happen.  I also never run into the situation where a bunch of tests are all of the sudden failing.  As for the number of test cases, I've never had a need to know.  But his points are definitely valid.
4. Tests aren't isolated.  You don't start fresh each time.  Thus, earlier tests could have unwanted side effects.  You have to be aware of this.  I either want side effects (as in the Order example where I'm building up an Order) or I simply start with an empty production object and build it up in the helper test method.

Coding By Intention

Originally published 10 Jan 2006

I thought I'd start blogging about something I think I'm pretty decent at - programming.  Yeah, yeah, I know, everybody thinks they are the best programmer, but I think I have some decent stuff to share.  I wanted to start with programming tips.  I'll try one tip per blog entry.
The first tip is coding by intention. The first time I learned of this was in college. I was reviewing some code with a professor of mine, Dave Binkley of Loyola College. We were reviewing a long method of mine and Professor Binkley said something equivalent to, “I like to extract a method here to make it more clear what I’m doing.” The light came on. I learned that programming was more than just a science, but an art. This was back in the early 90s, before the Extreme Programming/Agile folks coined terms like “extract method”, “refactor”, and “code by intention”.

Now, I'm a big fan of Test-Driven Development (TDD).  Since I've got to write a test first, I start there.  The real code doesn't exist yet.  The intent part starts here.  I think, "I've got this piece of functionality to implement.  What would I call if I could write anything?  What would the method name be and its arguments?  How would I call this functionality as a client so that what I'm doing is crystal clear? The world is my oyster."

Coding by intention from the point of view of the test is pretty obvious.  What I wanted to emphasize in this blog entry is to continue coding by intention all the way through until you've completely implemented everything.  So after you've created a new call in the test, you start implementing it.  It'll most likely be a public method.  When you're implementing this, you continue coding by intention.  You could just crank out a possibly long method to get the functionality implemented, but that's not what I'm talking about – that’s what I did in the early days of college.  The public method now becomes like another client.  You code by intention here, asking yourself what you would call if what you needed already existed.  You keep doing this with every method you need to implement, creating lots of small, but communicative and easy to understand methods.  Eventually, you'll get to a level where the implementation is small and simple and you're done.  What you've done is created some possibly reusable and very easy to maintain methods along the way.

It’s time for an example. Suppose I’m working with the usual Order/Line Items web site shopping example. One coding by intention technique I use when I need to process a collection like LineItems looks like this:

    public void processLineItems(List lineItems) {

        Iterator it = lineItems.iterator();

        while (it.hasNext()) {

            process((LineItem) it.next());

        }

    }

Instead of writing all the code in the while loop to process an item, I code by intention, pretending that the process(LineItem) method already exists.
Here’s another, albeit obviously contrived example. Suppose I’m working on Goldilocks’ Porridge class and need to implement the isJustRight() method. Right now I just have:

    public class Porridge {

        private double currentTemperature = 0.0;

       

        public Porridge(double currentTemperature) {

            this.currentTemperature = currentTemperature;

        }

    }

To implement isJustRight(), in coding by intention style, I would do:

        public boolean isJustRight() {

            return (notTooHot() && notTooCold());

        }

So why code by intention? There are several reasons I can think of off the bat. The first is, as I’ve stated above, you end up creating small, possibly reusable methods. My first tip was going to be “create small methods”, but I realized that coding by intention drives that. In my next entry, I’ll go into more detail on why I think creating small methods is really important. There’s a process to crafting elegant software and this is the first step.

Another reason is that the top level methods become really easy to understand.
They describe the algorithm in almost pseudo-code level. They communicate your intent of what you’re trying to accomplish step by step.

Yet another reason is that it is sometimes hard to get started on a task and by coding by intention you are delaying all the details, but still getting things done. That is, not everything you need is available, but you’re coding like it is. You’re working top down, drilling down into the details level by level until your done, making progress along the way.

Now, if you’re doing true TDD, you are writing just enough test to get a failing test, and just enough code to pass that test. Remember, compiler errors count as failures. I’m a little lenient on this practice. I like writing an entire test method for one test case scenario before going to the code. So in the isJustRight() method above, I’d first write a complete test method for a Porridge object that is too cold with all its calls and assertions. Then, I’d write just enough code to get the test to pass, but still coding by intention in the Porridge class. So, in this case, the isJustRight() method would just call notTooCold() for now.

I suppose if you truly wanted to follow TDD, and in particular, get a passing test as fast as you could, you could just write the code in isJustRight(), then extract a notTooCold() method. Just remember to do this. Sometimes, we as programmers get a little lazy. Still, I favor coding by intention top down from the beginning.

Well, that’s it for my first blog. Hope you enjoyed.