I want to talk about essence vs. ceremony in unit testing.

If I give you this:

OrderTest
    testCalculatePrice
        1 20.00
        2  5.00
          30.00

Can you tell what this is about? This is a specification of the calculatePrice() method on an Order object, where there are two LineItem objects and the expected price is $30.00. Did you figure that out without the explanation? This is essence.

Instead, what you often see is something like this:

public class OrderTest { 

    @Test
    public void testCalculatePrice() {
        Order order = new Order();
        Product product1 = new Product(20.00);
        LineItem lineItem1 = new LineItem(1, product1);
        order.add(lineItem1);
        Product product2 = new Product(5.00);
        LineItem lineItem2 = new LineItem(2, product2);
        order.add(lineItem2);
        assertEquals(30.00, order.calculatePrice());
    }
}

Here, you're blinded with irrelevant details that obscure what this test is all about. The essence of the specification is buried in details. What you want is clarity at this level.

You can factor out the obscurity with something like this:

public class OrderTest {
    private Order order = new Order();

    @Test
    public void testCalculatePrice() {
        lineItem(1, 20.00);
        lineItem(2, 5.00);
        expectPrice(30.00);
    }
}

That's gets us about as close as we can in Java.

A consequence of this approach is that you have more methods overall, but I've always felt that clarity trumps in specifications. Others have agreed.

What's interesting with these helper methods is that I can change how I implement them and not change the higher level, essence methods at all. For example, in lineItem() I can inject real production objects (as I did in the original example with LineItem and Product), or I can inject a mock or stub LineItem.

So my suggestion is when you are specifying these high level methods, attempt to only show the essence of the test and factor out the ceremony.

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.

It's inevitable. As more and more features are added to an application, the code base grows. The build has more to do: more compiling, more tests and metrics to run, more reports to generate. We've done numerous things to keep the build time down. In this entry, I'd like to describe one of them: running standard JUnit tests concurrently.

A colleague of mine came up with this idea. He first did a preliminary search to see if anything already existed.  Pretty much everything he found was intrusive, e.g., requiring extending a specialized TestCase.  He then attempted to combine Ant's Parallel and JUnit tasks. That is, he could simply nest N number of JUnit tasks inside a Parallel task. The problem here was coming up with a good way to divide the tests up into equal parts beforehand. My colleague quickly scrapped this idea in favor of a custom Ant task that wrapped the JUnit task.

The thought was to leverage the JUnit task as much as possible, but fronting it with the ability to run tests in parallel. The conceptual design looks like this:

There are N number of TestExecutors. A TestExecutor runs in a single JVM. Thus, there are N JVMs. Say we have a dedicated, 4 processor integration machine running builds. We may choose to configure our custom task with 5 TestExecutors (we'll add one assuming we're not 100% compute bound). Note: if you're familiar with the JUnit task, you may be wondering how its fork/forkmode attributes fit in. The answer is that they are eliminated in favor of this jvm-count attribute.

There's a single TestProvider. His job is to gather all the tests and hand them out one at a time to whichever TestExecutor is ready. A simple protocol exists to let a TestExecutor tell the TestProvider that he's done and ready for another test.  This should maximize parallelism.

The biggest negative with this approach is that since all tests run in a fixed number of JVMs, there's some loss of isolation here. Class level/global state set from a previous test could affect later tests. We're willing to trade this for increased performance.

The other possible downside is the use of a non-standard Ant task.

Using this approach we've successfully reduced our build time to usable levels.

I disagree with this stance, but I think Harold has a really good idea there, which I'll get to in a moment. I think breaking the build does include passing all the unit tests and should be part of the continuous integration process. I've always liked the idea of the tests serving as a safety net when I add new functionality or refactor existing code. The tests not only specify the desired behavior, but act as a regression suite.

So what's the idea? I first learned of the concept of test categorization from Cedric Beust's TestNG framework and the writings of disco king Andrew Glover . Essentially, the concept is to break tests into groups such as unit, component, and system and run them at different intervals. Unit tests are run many times a day as code is developed, component tests less frequently, and system tests the least frequently of all. You can categorize tests in several different ways such as by file naming conventions, placing them in different directories, or using Java annotations.

Harold brings up a new category - the todo category. (I was originally thinking the fixme category, but I thought todo could serve more purposes.) The todo category contains all tests that serve as a reminder of work to do. They obviously fail or there would be nothing to do. When it's finally time, the test moves out of the todo category and into the unit, component, or system category as appropriate. Although you could have a todo category for each of the original, regression categories (todoUnit, todoComponent, and todoSystem), I think that would be overkill. Notice that I slipped the word regression into "original categories" above. I'm advocating that the original categories should pass at all times - they should break the build if they fail (well, at a minimum the unit category). Once tests get into the regression categories, they never go back to todo.

The obvious downside of this approach and of test categorization in general is the added complexity. It's more work to maintain categories and in this case, move tests into different categories than a simple one category fits all approach. Also, there's more work (at least initially) to setup the running of those categories. As always, I recommend weighing the options and deciding what's best for your particular situation. See Glover's writings for more benefits of test categorization.

Let's quickly look at an example, the idea stolen from one of David Chelimsky's blog entries about specifying the behavior of a stack. We're focused here on the specification of an empty stack:

// notice the class name specifies the context
public class EmptyStack {
    private Stack stack = null;
    
    @Before
    public void setUp() {
        // set up the context
        stack = new Stack();
    }
    
    // notice the name focuses on the context
    @Test
    public void shouldBeEmpty() {
        assertTrue("not empty", stack.isEmpty());
    }
    
    @Test(expected=EmptyStackException.class)
    public void shouldComplainOnPeek() {
        stack.peek();
    }
    
    
    // more specification focused methods
}

The point here is that you can get many of the benefits of BDD (a focus on specification rather than testing) using the familiar JUnit framework.

Now, if you're a hardcore BDD'er, then you might complain that you still have to use a test-centric vocabulary. You still need those Test annotations and method calls like assertEquals rather than Dave Astels' preferred shouldEquals calls.

Also, from the legacy side of the fence, you lose the convention of method names starting with testSomething and class names ending with Test. It's sometimes hard to let go of that if you've been writing tests for a long time and it's super clear to spot those test methods and test classes if you're following a naming convention. Furthermore, Ruby on Rails has taught us that convention is a good thing. The test method naming convention doesn't really bother me so much. The @Test annotation makes things clear enough and shouldSomething really gets us focused on specification. However, I haven't let go of ending the class name with Test. Maybe it's more because Ant can pick those tests up easier if there's a standard naming convention.

The last negative I can think of is that of consistency. Having a mix of old style test centric tests and BDD style tests could bother some.

So, let's be honest. What am I really doing? Well, I am incorporating more and more BDD into my work. However, I still shy away from creating new classes. The BDD style really lends itself to many test classes (contexts) per class under test. In the case of Stack, as David Chelimsky points out, you'd also need AlmostEmptyStack, AlmostFullStack, and FullStack classes to fully specify the behavior. I just can't commit myself to writing all those. But I am focusing more on the set up of a context and the specification methods of that context. I just may cheat a little and combine contexts into a single class. So perhaps in the Stack example, I'd combine the empty and almost empty stack contexts under one test class. You know, I'd set up an empty Stack in setUp and for the almost empty context, I'd do a little more set up (push something) in the appropriate shouldSomething methods to make it almost empty.

I also revert back to legacy style testing sometimes. This is usually when I'm modifying an existing, old style test. It's just simpler and faster, and typically the context isn't set up too well for the BDD style.

So my advice is to use the right tool for the job. Use BDD style when that makes things clearer and you want to focus on specification. Use test centric style when that's easier. Try to do a better job of focusing more on specification and less on verification, especially when you're adding new behavior.

So if I had a method like this:

    private void someHelperMethod() {
    } 

I'd expose it like this:

    /** Exposed for testing purposes only. */
    void someHelperMethod() {
    } 

I'd laugh at people who used the <code>PrivateAccessor</code> of the JUnit-addons project or directly used reflection to get the method and do a <code>method.setAccessible(true)</code>. I'd think, "What's the big deal? Just change the access of the method. Then, you'll make things easier for your IDE when you want to do a method rename refactoring or just find references to this method."

I've recently hopped the fence and I'm now campaigning for the other side.

Now, before I get into the why, I should point out that red flags should have gone up after you read the first question of this entry. Testing private methods? Why would you do that? Believe me, as I've mentioned here , I think unit tests should focus on black box testing as much as is practically possible and therefore, you shouldn't be testing private methods. I'm also familiar with the argument, "You could perhaps move those private methods to a helper class and therefore, they wouldn't be private." But I still believe there are cases where it makes sense to (have and) test private methods. And in this blog, I'm talking about these exceptional cases.

So what are some exceptional cases? Think of a high level method specifying the steps of an algorithm or a method on a mediator/controller-like class collaborating with multiple objects. You did break that method up into smaller, easier to understand, more communicative methods as described here , didn't you? So which is easier: setting up the object under test and its collaborating objects (the fixture) and calling the private helper method directly; or setting up the fixture and calling the public, higher level method that does some processing before calling the private helper method? In the latter case, you surely had to do more set up to navigate down to the same entry point in the private method. If you didn't or it wasn't much more work, then I'm talking about a different context.

All right, so why the switch? Well, first off, the real intent is to make them private. Private leaves no doubt that the method isn't meant to be used outside the class.

Along with that is encapsulation. As multiprocessor systems become more mainstream, exploiting concurrency by multi-threading adds complexity to software development. Encapsulating as much as possible can only simplify reasoning about thread safety.

One final reason is that making things private helps static analysis tools like FindBugs and PMD better identify dead code that can be eliminated. "Hey, this method is private and it's not being called!" Keeping the code base lean and clean is a key to maintainability.

The biggest downside, as I've hinted at above, is doing things like renaming/changing the signature of the method, or just finding references to it. The IDE won't make the appropriate changes to the test or find the reference in the test. But you'll find this pretty quickly when you run the test and it fails. Hint: Maybe you should have changed the test first anyway.

So join me on this side and remember that testing privates is better meant for special cases.

I'm going to base my example on Spring's BeanFactory interface. Suppose I'm developing a Map backed BeanFactory and I am currently focused on implementing the following method of the BeanFactory interface:

Object getBean(String beanName) throws BeansException

Let's call the class I'm developing MapBackedBeanFactory. When getBean() is called, the implementation will look up the bean in its beanMap field.

When I think about test cases, I think about:

1. The state of the object under test (each field), i.e., the fixture. In the example, this would be the beanMap.
   
2. The state of the parameters of the method I'm calling on the object under test. In the example, there's only one: the beanName.

That was pretty obvious. Who doesn't think about these things? But what is the checklist? The checklist consists of thinking about the following for each of the above:

1. A good value. This will execute the normal flow and is the most obvious test. For beanMap, this means the beanMap will have a good bean mapping. For the beanName, a good value is a name that will be found in the beanMap. There may be multiple good values, not really in this case, but think about the classic bowling game. You'd want tests for a non-mark frame, a spare, and a strike. I'll also consider multiple good values for things like collections, maps, and arrays. That is, maybe I'm dealing with a  List and I need a List of two good things. However, I find that most times, one good value in the collection, map, or array is sufficient.  This is because I write the iteration code for the single case and a multiple collection test case wouldn't make me write any new code.  If I find I need multiple good values, I'll start with the simple cases and work towards the harder.
2. A negative case. In #1, I set up the fixture and parameters to get a good result.  Now, I want to think of the negative side.  So I found beans in #1, but now I want to not find a bean.  Pass in an unknown beanName.
3. A null value. What if the beanMap were null? That's probably not realistic, so I'm going to skip that. What if the beanName were null? That's possible and according to the BeanFactory JavaDoc, it looks like the contract specifies to throw a NoSuchBeanDefinitionException. I better write that test. Many times, if you don't handle null, you'll get a NullPointerException and that might be acceptable. In those cases, I wouldn't write a test (since it wouldn't require any code).
4. An empty value. The beanMap could have no mappings or the beanName could be "". I think #2 covered us here, so no test is required.
5. An invalid value. What if beanMap were invalid? What if it were a Map of Integers to bean Objects? I'm going to assume this is unrealistic in this case. We would have handled such a situation when the map was loaded.  What if the beanName were "invalid"? Well, we covered that in #2.
6. An exceptional case. I'm pretty much talking about handling exceptions here. Maybe we need to write a test case to see if we handle an exception properly. The example doesn't have such a case, but suppose the method under test were doing some I/O. Maybe we'd need to write a test to see if we handled that properly. In all honesty, even though I think about this, I don't usually write a test to handle exceptions. I won't get 100% test coverage, but I usually ignore writing the test because checked exceptions force me to write the necessary handling code.

That's a lot of stuff to think about for each object field/parameter. That's the biggest negative - thinking about all those things, all the possibilities, all the time it takes. Many times, as you saw in the example, most of those things just aren't realistic.

Sometimes I'll take a different approach. I'll start with the simple, good case. I'll write the test and get it to pass by writing the minimal code to do so.  In the example, I'd have:

return beanMap.get(beanName);

Then, I'll look at the method I just wrote word by word (or maybe token by token).  At each word, I'll think about special cases (things like in the checklist) and jot down test cases. Then, I'll go back to the test, write one of the jotted-down tests, get it to pass, and continue until I'm done. It's a different perspective that goes a little faster at the risk of not quite catching everything as the first approach.  I like this second approach and have been doing it more and more lately.

I’ve been noticing that I sometimes feel a need to go back and modify my test to be more in line with the object it’s testing. And I’m not alone. David Chelimsky recently wrote a related blog. That blog, in the context of my goal, focuses more on changing tests because they start drifting away from the code they’re testing.

In this blog, I want to talk about changes required because the tests break as a result of good refactoring. This isn’t something that occurs often, but it does happen, and I think it’s a code smell. One of the main advantages of having a test suite is that you can refactor to make the code better or try a different algorithm without worrying whether the final result broke existing functionality. When the tests break as a result of correct refactoring, I lose that safety net kind of feeling.

So what does it mean when a test breaks as a result of good refactoring? Well, what jumps out is that the test is too coupled to the main object it’s testing. However, it is a unit test and unit tests are traditionally white box tests and white box tests imply knowledge of the code and that implies coupling.

What about a black box approach to unit testing to reduce coupling? Elliotte Rusty Harold recently posted a comment on one of his blogs Experimental Programming, “The class is a black box which is accessed solely through its public interface. The internal details are deliberately opaque, and thus can be changed as necessary to improve performance or other desirable characteristics without breaking client code.”

Yeah, that’s what I’m talking about, but I think a total black box approach would be too coarse grained, particularly for ensuring 100% test coverage. Specifically, I’m thinking that touching every conditional statement would require a lot of black box test code. I think the first tip then is to find a balance between black box and white box testing; the sub-goal being to find the appropriate coupling to get 100% coverage with the least amount of test code. I’m trying to keep this in mind when I write tests.

Another technique to help achieve the goal is to shy away from mock objects, particularly strict mock objects. Martin Fowler wrote an article called “Mocks Aren’t Stubs”. In it, he describes the difference between mock objects and stubs. He also describes two styles of testing: state-based and interaction-based. Interaction-based testing uses lots of mocks, which really couples tests to the implementation details. This is not what I want if I want to achieve my goal. So I prefer the state-based approach Martin talks about.

Now, having said that, I do use mocks in certain situations. They’re good at making sure your object made a call on a secondary object:

   public void testInitRegisters() {
      // setup a mock object that expects a register call
      // and inject it into the object under test
      objectUnderTest.init();
      // verify the mock
   }

Typically, I find that I use mock objects when I’m testing void methods, just like the init() method above. In fact, thinking more about it, it might actually be when the method I need to call on the object I’m mocking is void, just like register() method above. I’ll have to pay more attention, but that seems to make sense. The point is to use mock objects only when they are more practical than the state-based approach, preferring the state-based approach otherwise to reduce test coupling.

Stubs are great for tests whose primary object calls methods that return values from secondary objects. I use mock libraries to create stubs, particularly for Interfaces and expensive-to-create classes, since it’s so easy to do so. I reduce test coupling by creating lenient stub objects that either ignore unexpected method calls or return empty values (0, null, false) for unexpected method calls. In EasyMock terms, I’m talking about nice controls.

I also use the Object Mother pattern as a factory to create the stub objects. This is so that the stub creation code can be shared among many test classes. I pass the values I want returned into object mother. The object mother creates the stub object with those values. In this way, the test has all the knowledge of the canned results. Then I use a state-based approach to verify everything. Here’s a quick example, putting this all together:

   private Order order = new Order();

   public void testGetTotal() {
      // LineItem is an interface.  LineItemMother uses a
      // mock library for creating a stub LineItem
      LineItem lineItem = LineItemMother.newItem(3, 2.50);
      order.add(lineItem);
      assertEquals(7.50, order.getTotal(), 0.001);
   }

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

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);

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.

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

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

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:

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.