James Carr

In my earlier post I showcased doing a simple factorial code kata using scala and today as I was driving home from work I was thinking… isn’t there some way to dynamically add methods to an object so that I can just write 10! and have it compute the factorial?

The answer is yes, kind of. You don’t really define a new method that gets tacked onto an existing type, but rather define an implicit method that gets called to “implicitly” convert one type to another.

Read More »

So recently I started committing myself to understanding scala better and a perfect way of doing this is to start practicing different code katas in the language. So early this morning I started the day by doing the Prime Factors Kata in scala using specs to drive development and sbt to build run tests. The thing I really like about sbt is you can run ~test and just like ZenTest file changes triggers all the specs in the project to be re-ran.

Overall my solution was pretty simplistic and comes from a java developer’s understanding of scala. I spent 30 minutes on it and shared the result on github under scala-prime-factors. Feel free to criticize to your heart’s desire and let me know of better ways of solving this… I keep feeling like there must be a simple scala one liner that I just don’t know about.

For those who are lazy, here is the spec:

import org.specs._

class primeFactorsSpec extends Specification {
  "should generate empty list for 1" in {
    primeFactors.generate(1) must be equalTo(List[Int]())
  }
  "should generate a list with 2 in it for 2" in {
    primeFactors.generate(2) must be equalTo(List[Int](2))
  }
  "should generate list with 3 in it for 3" in {
        primeFactors.generate(3) must be equalTo(List[Int](3))
  }
  "should generate a list with 2 and 2 in it for 4" in {
    primeFactors.generate(4) must be equalTo(List[Int](2,2))
  }
  "should generate a list with 2 and 3 in it for 6" in {
    primeFactors.generate(6) must be equalTo(List[Int](2,3))
  }

  "should generate list with three 2s for 8" in {
    primeFactors.generate(8) must be equalTo(List[Int](2,2,2))
  }
  "should generate list with two 3s for 9" in {
    primeFactors.generate(9) must be equalTo(List[Int](3,3))
  }
}

And here is the terrible looking solution:

object primeFactors{
  def generate(n:Int) = {
    var x = n
    var factors = List[Int]()
      for(i <- 2 to n)
        while(x % i == 0 && x/i > 1){
          factors += i; x/=i
        }
    if(x > 1)
     factors += x
  factors
  }
}

For those of you who are attending my TDD class tonight, you’ll realize that I mentioned several times that learning to use test doubles effectively takes time… I’ve been using test doubles in my tests for half a decade and I still learn something new everytime.

I’ve included some links to material to help you learn more but it will take time for it to soak in.

• Mock Roles Not Objects (related presentation)
• XUnit Patterns on Test Doubles
• Mocks Aren’t Stubs
• Inversion of Control (not about test doubles per se, but plays a large part in using test doubles)

In my previous post I went over some of the new annotations and annotation features available in Mockito with the 1.8.3 release and promised the following day I would post details on the @Spy annotation. Well, unfortunately practically a month has passed since then! But fear not, here is the overview of the @Spy annotation that I promised.

Using It

Using the @Spy annotation is quite easy… just use the MockitoJunit4Runner and annotate a real object instance as follows:

import java.util.ArrayList;
import java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;
import static org.mockito.Mockito.*;
import static org.junit.Assert.assertThat;
import static org.hamcrest.CoreMatchers.*;

@RunWith(MockitoJUnitRunner.class)
public class SpyExample {
	@Spy
	private List<String> list = new ArrayList<String>();

}

This will essentially proxy the real ArrayList implementation with a CGLib proxy. No big deal there. Let’s try stubbing a call so that it returns “hey” if we request index 32:

        @Test
	public void spyExample(){
		when(list.get(32)).thenReturn("hey");

		assertThat(list.get(32), equalTo("hey"));
	}

This blows up in our face with a big hairy IndexOutOfBoundsException while trying to stub the method call out. Duh… it’s calling the real implementation! Therefore we opt to use doReturn(...) instead as it allows us to stub the method we want without calling the real thing.

@RunWith(MockitoJUnitRunner.class)
public class SpyExample {
	@Spy
	private List<String> list = new ArrayList<String>();
	@Test
	public void spyExample(){
		doReturn("hey").when(list).get(32);

		assertThat(list.get(32), equalTo("hey"));
	}
}

If we rerun the example we will now see green bar rather than IndexOutOfBoundsException. We can still call real methods like add, remove, size, etc and they’ll still behave as expected; only when get(32) is called will it stub the call and return the canned value.

For the most part, I’m not a fan of this technique. In the real world I’d either choose between using the real thing (which I would most certainly ALWAYS do if it were a collection or some other base type) or prefer a wholesome complete stub using @Mock (but adhering to the rule that you only mock/stub objects you actually own).

Sadly there are always weird cases where you need to do it to make something easier to test… a good example was some legacy code I was dealing with where the test interacted with a real object to manipulate graphics in the UI. Those interactions needed to remain intact in order for the existing tests to pass, however one method caused a web service call that made the tests brittle and unpredictable. Spying that object and stubbing out the method that made the web service call was the best way to exercise the different scenarios around what that method returned. “Fixing” the collaborator’s API itself or isolating it from the class under test is a whole separate issue.

Verifying Messages Between Collaborators

A really useful feature I find in using spies is the ability to verify messages passed to a real collaborator in a big ball of mud type of system. Imagine this scenario: you pick up a story that is to just modify some logic in how messages are passed from one object to another. Sounds simple, until you look at the existing unit test:

public class CustomerHandlerBOTest {
	private ComplexClassThatDoesAlot formulator = DumbStaticFactory.create();
	private CustomerHandlerBO bo = new CustomerHandlerBO(formulator);

	....
}

The class names and that static factory are bad enough, but let’s imagine the code has gotten itself to the situation where simply providing complete test double for ComplexClassThatDoesAlot will force you to introduce test doubles for 20 other objects. Or perhaps the method is large and the default behavior of the collaborator allows you to execute the code that needs to execute to get you to where you want. You can simply write a verification of the argument passed to it and then make the modification you need to.

@RunWith(MockitoJUnitRunner.class)
public class CustomerHandlerBOTest {
	@Spy
	private ComplexClassThatDoesAlot formulator = DumbStaticFactory.create();
	@Captor
	private ArgumentCaptor<Item> arg;
	private CustomerHandlerBO bo = new CustomerHandlerBO(formulator);

	@Test
	public void shouldPassItemRequestWithExpectedCalculation(){
		...
		bo.calculate(BULK_ORDER);
		verify(formulator).audit(arg.capture());

		Item actualItemAudited = arg.getValue();
		assertThat(actualItemAudited.getPrice(), equalTo(EXPECTED_CALCULATED_PRICE));
	}

Of course, once the tests pass I might start applying some obvious refactorings starting as renaming away from those hideous names and either eventually get to the point where a @Spy is no longer needed or at least have that piece under test. The good thing about this is you can verify the interaction between these two objects without having to crack open encapsulation through a backdoor default or protected method (something I’ve been guilty of).

You Can Stub Internal Calls

I’ve seen situations where someone was dealing with legacy code and wanted to do this:

doReturn(1).when(bookingSystem).getActiveReservations();

bookingSystem.processReservations();

Where processReservations() makes a call to getActiveReservations() internally. Although this clearly hints at a hidden collaborator that needs to exist or break free from bookingSystem, Mockito apparently will let you get away with this. I seriously wouldn’t suggest it when test driving fresh code, again but there’s always those situations where you have no options.

Hope that is useful for you… overall I find the @Spy annotation to simply be a useful tool for fighting legacy code but should be used with care when specifying fresh code, if at all.

I’ll be giving a presentation at Lambda Lounge this Thursday on Behavior Driven Development With Jspec. If you’re in the St.Louis area come on by and learn about BDD and how you can use it to drive your design. I’ll be using jspec to demonstrate how to build a functioning feature for a javascript library driven by small, iterative examples.

Although the cookbook includes an example of using the easyb ant task to run specs and produce reports, I thought I’d try my hand at writing a task to manually run easyb specifications from the commandline. Here’s the result:

task spec <<{
    ant.java(classname:'org.easyb.BehaviorRunner', fork:false,
      classpath: "${sourceSets.test.runtimeClasspath.asPath}")  {
        sourceSets.test.java.srcDirs.each { testDir ->
            testDir.eachDirRecurse { dir ->
                dir.eachFileMatch(~/.*\.specification/){spec->
                    arg(value:spec.absolutePath)
                }
            }
        }
    }
}

Now I can run “gradle spec” from the commandline to write all my easyb specs. Spock is next.

I’ll admit I’ve just recently gotten back into groovy, so I’m still kind of a noob. I keep feeling like groovy has a better way to search for file patterns recursively.

Over the past four years I have at various times over and over explained to my co-developers why writing tests against setters and getters is bad, dealt with the whole “metrics” argument, and quite frankly I start to get weary repeating myself every three months.

While I was driving into work today, I started thinking about the subject again as I’ve been debating a topic yet again recently that I quite honestly don’t think it warrants any debate and decided that since I haven’t written any blog posts on the subject, I should. So ahead I will describe why test driving setters and getters isn’t only a waste of time, but it is also considered harmful to your design as well!

First off, I’ll point out why I find it a waste of time. I’ve seen developers labor furiously in the past to verify that a behavior that at the simplest is already done for them by their IDE. If your IDE has generated them for you, and you decide to write tests against it, you’re first of all bullshitting yourself that you’re practicing TDD, because you’re really writing tests after the fact. Secondly, what the frak are you testing? That the developers of intelliJ/eclipse/textmate/whatever wrote their setter/getter generation code correctly?

Another myth is that, while the above argument is correct, the setter/getter “might” have some behavior in it, or if you don’t write a test against it and someone goes in and modifies the behavior, there will be no “tests” to catch it. Now, I can’t say for you, but I don’t write tests to “catch bugs”, I do it both to prevent them and to ensure my design is sound. Secondly, I also adhere to concepts like YAGNI (You Ain’t Gonna Need It) and creating “The Simplest Thing That Can Possibly Work.” If I’m going to change the behavior of my setters or getters, I’ll write a test for that behavior before I change it. If you’re trying to prevent developers from being sneaky, well then you have team issues that you need to address, and I don’t think the best way to deal with those team issues is by decreeing that all setters and getters need to be tested.

These are all perfectly good reasons not to test setters and getters in my humble opinion, but now let’s get to the real reason you shouldn’t do it, and why I even considered it harmful to your design. See, when we practice Test Driven Development, there really shouldn’t be so much of an emphasis on “test” but rather on “design” (this is why I really lean toward using the term Behavior Driven Development). I’ve said this before, but let me recap.

We use tests to drive our design. Each test provides an example of functionality that we use to prove the need for the code we’re going to write to exist. With a failing test in place, we then write the code that we need to make that test pass, then on to the next. Using this iterative approach, we allow our system to take part in emergent design, proving we really do need the code we’ve written. If we wrote code we didn’t write an example for, there’s the possibility that we really don’t need that feature (or we do, we just thought too quickly and didn’t write an example). Setters and Getters should get exercised while executing these examples.

Wait, back up. “Setters and Getters should be exercised while executing these examples.” What I mean by this is that when you write a test against a feature that, let’s say returns an object, you should be doing a verification on that return value’s field to see if a value was set to the expected value, in which case in the course of that test the setter and getter get executed. The example for that specific feature proves that you need that field to hold some value.

A simple example:

@Test
public void shouldAddDiscountIfTenOrMoreItems(){
	Order order = new Order();
	order.setItems(add(10).items().thatCost(ITEM_PRICE));

	calculator.calculateDiscount(order);

	assertEquals((ITEM_PRICE*10)*0.20, order.getTotal();
}

Now in this example, we exercise various setters and getters in Order, because we need them. That’s right, because we need them… our feature that our business cares about needs them in order to work.

Now we lead ourselves to why TDD’ing setters/getters is harmful… by writing tests against setters and getters, we’re saying that we need these properties on an object, but we’re not explaining why. This is akin by starting a project by hitting the ground running and designing the database without no real understanding of how the data will be used. At the least you’ll possibly be defining objects and properties you might night use… at worst, you’ll create a design of objects that aren’t grouped within the domain correctly, which will show itself overtime when you have domain objects and services that, although they work, don’t make a lot of sense.

This is a good middle ground for people concerned with metrics. Although I think that high code coverage is a side effect and not the end goal, if you follow this practice you should achieve optimal code coverage without succumbing to wasting your time testing field names.

UPDATE: Pat Maddox posted a link on the TDD mailing list to an old (but rather insightful) article on why getter and setter methods are evil. I’ll have to say I agree with this quite a bit!

Earlier I spoke about specifications at the story level, now it’s time to explore them at the unit level. Story level examples explore how the feature in it’s entirety works, demanding code to be produced to make the example work… at the unit level, we apply the same concept, we provide examples that prove the need for code in our class to exist and then write code to make that example work.

Examples, or Exemplars

The basis for this are Exemplars, which we saw earlier in story level specifications, but just to recap they are somewhat equivalent to scenarios consisting of the structure

Given (Some Context/Precondition)
When (Event Happens)
Then (Outcome)

You might recognize this structure from an existing TDD practice of “Arrange, Act, Assert.” Hypothetically I like to think of this as the same format and we should aim to keep each three phases of the exemplar as small as possible. In JUnit I might write an exemplar somewhat like this (using an example from the BDD wikipedia page):

	@Test
	public void shouldNotBeEmptyWhenListHasMoreThanOneItem(){
		List<String> list = new ArrayList<String>();

		list.add("foo");

		assertFalse(list.isEmpty());
	}

In the above example, the given/when/then would be

Given a new list
When an item is added
Then the list should not be empty

From there I’ll create more examples of how the API should work, refining and adding examples in an attempt to “break the model”, that is attempt to define examples that break my assumptions on how the API should work and even provides better insight on what roles/collaborations my object might have. Now this doesn’t mean wasting time by passing null to every method call or writing fifty exhaustive examples with every possible input known to man, but rather finding examples that could prove that my domain logic is incorrect… by doing so, I’m able to reflect on my current API design and refine my model.

The main process at work here that ties this together is something I first saw at a Real Options based presention (as well as in the comic I mentioned in my earlier post): David Kolb’s learning styles model which I think accurately reflects the development cycle that one often uses when applying BDD style practices. To break the process down into Kolb’s Cycle:

1. Concrete Experience: seek challenge and immediate experience - I like to think of this as coming up with the first example and writing code to make that example work
2. Reviewing the Experience: ’stand back’, gather data, ponder and analyse - We wrote an example with passing code, what have we learned from this experience? I also like to think this is the point where we might refactor, not only to clean code up, but to refactor toward deeper insight.
3. Concluding from the Experience: think things through in logical steps, assimilate disparate facts into coherent theories - we’ve analyzed the example and solution, refactored towards deeper insight, now we have several ideas of where to go next
4. Planning the next steps: seek and try out new ideas - this connects us back to step one, we try out successive examples and new examples we’ve come up with, and we’re not shy to try an example out and discard it if it’s incorrect

I know that sounds like quite a bit of work, but I often find that this process occurs naturally and can be pretty rapid, building each example off of the previous examples, seeing patterns and refactoring, and even eliminating bogus examples. Especially if you’re pair programming it helps if you are doing “ping pong” style pair programming: writing the first example, your peer writes just enough code to make the example work, then uses his concrete experience to write the next example for you to write code to work.

So What’s the Real Point?

I think the biggest point to convey here is what the difference is between conventional “unit testing” and a BDD mindset… in the earlier, you might be concerned with testing your code but what you should do is be focusing on providing examples of how your code works and using those examples to prove the need for your code. That mindset coupled with writing examples in the Given/When/Then format keeping them simple and to the point helps you drive the design of your API and even provide some developer readable documentation on how the API works.

Next?

Again, I’m only barely scratching the surface… there’s a lot more to talk about, and a lot more to delve into in how best practices in TDD are present in BDD. I haven’t even covered any BDD specific spec frameworks, opting to provide examples only in JUnit! There’s also more to discuss on Contexts, Test Doubles, etc. Stay tuned!

For those of you who didn’t know, I’m currently contracted at a workplace that is still stuck using java 1.4 (I heard they might ring in 2010 by upgrading, but we’ll see). This has create a number of difficulties, chief amongst them (in my view) that I can’t use Mockito and most people use EasMock… version 1.2 (yeah, the one with that MockControl nonsense).

Not to be foiled, I used retrotranslator to translate mockito to 1.4 so I can use it for TestCases… it is now available on the Mockito project site.

This is pretty much a direct port, and I added the class MockitoTestCase which basically has all the methods you’d normally statically import off of the Mockito base class. Here’s a quick demo of usage:

public class CustomerServiceTest extends MockitoTestCase{
	private CustomerDao customerDao;
	private CustomerService customerService;

	public void setUp(){
		customerDao = (CustomerDao) mock(CustomerDao.class);
		customerService = new CustomerService();
		customerService.setCustomerDao(customerDao);
	}
	public void testShouldReturnTheNumberOfActiveAccounts() throws DataFormatException{
		List customers = Arrays.asList(new Customer[]{new Customer(3), new Customer(4)});
		when(customerDao.getActiveCustomers()).thenReturn(customers);

		assertEquals(7, customerService.getTotalActiveAccounts());
	}
	public void testShouldSaveCustomerIfHeHasAccounts(){
		Customer customer = (Customer) mock(Customer.class);
		when(customer.getNumberOfAccounts()).thenReturn(new Integer(1));

		customerService.saveCustomerWithAccounts(customer);

		((CustomerDao) verify(customerDao)).save(customer);
	}
}

Good Luck!

Continuing a trend of Mockito related articles, I thought I’d blog about using another feature I recently discovered while trying to figure out how to implement fine grained behavior in mockito.

First, let me set the stage… I had a method call I was writing examples for that was a typical Castor marshal operation, which often looks something like this:

StringWriter w = new StringWriter();
marshaller.setWriter(w);
marshaller.marshal(obj);
channel.send(w.toString());

Yeah I know… it looks like shit. But sometimes APIs force that on you. Anyway, I wanted to write an example illustrating that the channel received a message that was the result of whatever marshaller wrote to the output stream, but this was a little difficult to do (but easy to do with hard coded subclasses and lots and lots of boilerplate code).

The answer comes with, well, the Answer interface. To illustrate this, let me set up an example. Given I have started a unit test that looks like this:

@RunWith(MockitoJUnitRunner.class)
public class MessageServiceTest {
	@Mock private Marshaller marshaller;
	@Mock private Channel channel;
	private MessageServiceImpl messagService;

	@Before
	public void before(){
		messagService = new MessageServiceImpl();
		messagService.setChannel(channel);
		messagService.setMarshaller(marshaller);
	}

	@Test
	public void shouldWriteMarshalledDataOutToChannel(){

	}
}

We want to be able to verify that the channel (which is a simple interface with a send(String arg) method) receives whatever String the marshaller wrote to the provided Writer. Now, because the writer is constructed in the class itself, it’s difficult to stub this out. So in order to make the writer have SOMETHING written to it, we set up an answer to be invoked both when marshaller.setWriter(..) and when the marshaller.marshall(..) method is called:

private class MarshalAnswer{
		private Writer writer;
		public Answer<Writer> respondToSetWriter(){
			return new Answer<Writer>() {
				public Writer answer(InvocationOnMock invocation) throws Throwable {
					Writer w = (Writer) invocation.getArguments()[0];
					writer = w;
					return null;
				}
			};
		}
		public Answer<Object> respondToMarshall(final String writeThis){
			return new Answer<Object>(){
				public Object answer(InvocationOnMock invocation)
						throws Throwable {
					writer.write(writeThis);
					return null;
				}
			};
		}
	}

Bleh… lots and lots of boilerplate code because of the interfaces, but oh well. Here’s the revised test case in action:

@RunWith(MockitoJUnitRunner.class)
public class MessageServiceTest {
	@Mock private Marshaller marshaller;
	@Mock private Channel channel;
	private MessageServiceImpl messageService;
	private Invoice invoice;
	private MarshalAnswer answers;
	@Before
	public void before(){
		messageService = new MessageServiceImpl();
		messageService.setChannel(channel);
		messageService.setMarshaller(marshaller);
		invoice = new Invoice();
		answers = new MarshalAnswer();
	}

	@Test
	public void shouldWriteMarshalledDataOutToChannel() throws Exception{
		doAnswer(answers.respondToSetWriter()).when(marshaller).setWriter(any(Writer.class));
		doAnswer(answers.respondToMarshall("<someresult/>")).when(marshaller).marshal(invoice);

		messageService.send(invoice);

		verify(channel).send("<someresult/>");
	}
...

I could have just created the respondTo methods in the TestCase itself, but I wanted to keep it separated by putting it in a helper class.

So now we run the test and we should see the following:

Fair enough… lets add the following code to the method we’re describing and rerun:

public void send(Invoice invoice) throws Exception{
		StringWriter writer = new StringWriter();
		marshaller.setWriter(writer);
		marshaller.marshal(invoice);
		channel.send(writer.getBuffer().toString());
	}

We rerun and sure enough, green bar! The way it works is pretty simple… whenever setWriter gets invoked, the Answer object gets called and the argument is available within it (in this case the writer) which we can then store to use for the marshal call. When marshal gets called, our Answer we defined gets called and writes whatever we told it to.

While this does provide us with a useful tool when requiring some slightly complex behavior in our collaborator interactions (in this case, we essentially needed to capture what was passed to the writer, which was acting as a hidden output variable) I’d still recommend avoiding them when you can.