Ketan's Musings

A quote from a very reliable site on TDD

Testosterone Driven Development
The watchword of Extreme Programming is “Testosterone First!” Not a line of code is written without macho posturing for the benefit of the cameras, the rest of the team and any Code Babes that are hanging around.

This is in continuation to my previous post “Eclipse and TDD”

I feel that the question that I posted “Given this scenario, how do you do test-first-development ?” needs some clarification:

There’s one interface that needs to be implemented to accomplish a certain task. This one interface is supposed to return some more interfaces. Also you’ve never used those interfaces before, makes things unpredictable in some sense. You therefore end up taking small steps, try out a few things here and there, see what happens as you go along, and your implementations evolve quickly over the period of a few minutes. By which time your implementation is complete, and you have not written a single line of test

You then quickly get to refactor the code that you’ve written to make it “testable”. This code was never written with “testablity” in mind in the first place, so it will never be testable in a way that you really want it to be.

The problem to me seems to be the fact that the “expectations” from the interface are not known before the tests are written.

So does this mean that:

• I need to better understand the interface before I start using it ? Read the JavaDocs, other implementations that do something “similar” ?
• Assuming that I do understand (to some certain extent) what the intent of the interface is, and I go ahead and implement that interface — the test-first-way. I know for sure that this may not really work in a way that I want it to, so I can go ahead and change bits and pieces to suit my needs.
• Write a test harness like cactus for every such possibility — this I know is a crazy solution but one that would gurantee testability. This would also create additional problems of having to maintain the test harness at a pace equal to the pace of what the harness is trying to test.

It’s been after quite a while that I’m back to doing eclipse plugins. In this span of time I learnt some good techniques — TDD. It’s a really good safety check to know that your code is in a working state.

Test-first-development or TDD as it is called is where you generally write tests first and then write code that makes these tests pass. This in some ways ensures that you write clean APIs that are simple to test, use and understand. The APIs don’t really do more that what is needed for the job. So far so good.

The fun began when I moved back to doing eclipse. I now realize that it is difficult to do TDD when I’m writing code that implements (or extends) some third party interfaces. These implementations return some more interfaces, which only compounds to the problem of test-first-development.

The way I write eclipse plugins is create a null implementation that does nothing at all. It merely prints method names of the methods being called on to the console. I then start off eclipse (in debug mode), understand the sequence in which the interface is invoked, and what eclipse does with the return values (that’s walking though a lot of code, BTW), I also sometimes need to look at similar implementation to understand what they do. I then gradually implement those methods in a way that what eclipse expects. This gives another meaning to BDD — breakpoint driven development.

This process is what most developers would probably do when using a framework for the first time. Most frameworks (unlike the eclipse frameworks) are much simpler than eclipse is. There are some known interfaces that are exposed. Since there are very few interfaces to implement, developers gradually get to know them very well. As the expectation out of these interfaces is known well, gradual use of these interfaces, makes it easy to write tests for the interface before implementing the interface itself, which means that developers can move from BDD to TDD.

This process is a quick (and IMO, dirty) way of writing code. The initial code is not written with testability in mind, writing unit tests at the end is quite difficult, and testability can be achieved after quite some bit of refactoring to allow make the code testable.

An example of this is a typical java webapp that consists of some servlets, and jsps containing tag-libs etc. There are very few known interfaces that the clients implement (the HttpServlet, Filter, FilterChain etc.) Since the webapp framework itself is very compact, a framework to unit test the implementations of interfaces exposed by the servlet spec has evolved over a period of time. Cactus is one such example:

Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters, …) [...] It uses JUnit and extends it.

To test a servlet one would write a test as:

public class TestSampleServlet extends ServletTestCase {
  public void testThatServletPrintsHelloWorld(){
    Servlet servlet = new HelloWorldServlet();
    ...
    session.setAttribute("name", "bob");
    ...
    assertTrue("hello, bob", servlet.printHelloWorld());
  }
}

It is mind boggling to imagine a framework similar to cactus to test the thousands of interfaces exposed by a framework like eclipse, and we are still not talking about the other, “smaller” projects under the eclipse umbrella.

Given this scenario, how do you do test-first-development ?

From the article here by Roy.

Agile methodology intensely focuses on best practices such as iterative delivery, test-driven development, continuous integration, and agile testing which enables the developer to deliver high quality applications with unprecedented visibility of progress to customers.

Nirav contemplates on TDD:

To sum the experiences on evangelizing TDD:
To a good programmer explain the benefits of writing intellectual tests rather than idiot debugging every time. To a novice, give a real example; mock a bad situation and exhibit how to tackle it with TDD. To an amateur, explain how tests are better than manual troubleshooting.

Kill Debugging, Write tests.