This is a neat observation. One equivalent to test-Driven Development (TDD) when working with an existing codebase might be “test-driven refactoring”. The idea seems to be that at any particular point in the lifecycle of a software system not all of the benefits of TDD are actually being used. So why not just do enough TDD to get the required benefits at the time.
In this case the need is to refactor some existing code in preparation for a change. Rather than either (a) stop to write tests for the whole system, or (b) throw up our hands and abandon TDD for this work, the suggestion is to write a passing test around the exact code being refactored, then use that test to ensure that the change preserved that behaviour. Then, in the TDD style, rinse and repeat for the following refactorings.
As this progresses the result should be a growing body of regression tests. concentrating around the areas which have actually changed, which seems good to me. It’s not as good as TDD from the start, but it’s better than no tests at all.
Agile Tips: Testing private methods, TDD and Test-Driven Refactoring
I’d not seen this, and if you haven’t either then it’s well worth a read. Tim Ottinger gives a detailed list of the ways that Test-Driven Development (TDD) changes code.
Testing Will Challenge Your Conventions
I develop almost all my code these days using Test Driven Development (TDD). By taking this approach I never bother about unit test code coverage, but some developers seem very concerned by it.
One thing that I have never considered doing is retroactively adding tests just to increase some code-coverage metric. Dan Manges has written in interesting explanation of why that might be, using some examples in Ruby.
Dan Manges’s Blog - Increasing Code Coverage May Be Harmful
I’ll put my cards on the table. At heart I am a “classic TDD” guy. My first attempt at any new code is to test return values or side-effects rather than immediately jump to setting up mock objects and testing interactions. Although I do use mock objects as a testing technique from time to time I have never liked any of the popular mock frameworks. The nearest I have found to what I would like is probably Mockito, but even so I still use my own recording framework.
thekua.com@work ยป The world mocks too much
This is a great little summary. I think I’ll have to make a set of these cards to show and remind at any opportunity.
TDD on Three Index Cards
Steve Freeman has put together one of the most thought-provoking software development articles I have read in a long time - based on application of ideas from a New Scientist article.
Husbanding willpower | Steve Freeman
A few years go I wrote a series of articles for The Java Ranch Journal entitled “Small and Simple Web Applications - the Friki Way”. The series showed an example of developing a very simple wiki (collaborative editable web site) in Java using Test-Driven Development (TDD) and a form of agile project management.
From time to time I refer someone to these articles but it has been tedious to find and gather all the individual article links. This post contains those links, so I can just give out a single URL in future.
Unfortunately I never got around to continuing the series beyond that point. Maybe one day I should …
Mockito is a Java Mock objects framework which seems more usable than either of the main contenders (JMock and EasyMock). The project has just released a new version which now allows the attachment of a mock “overlay” to an existing object.
This has been on my “evaluate” stack for months, but (as Harry Pynn pointed out when he “vouched for” me) I tend to be more comfortable with “classic” TDD and don’t usually find much use for Mock Objects.
I have had a quick play with the examples of use on the Mockito site with mixed success. many obvious cases work well, but there are also some gaps in the way it works. For example, consider this small example test:
import static org.mockito.Mockito.spy;
public class PlaypenTest extends TestCase {
public void testMockito() {
List real = new ArrayList();
real.add("first");
real.add("second");
List ml = spy(real);
stub(ml.get(0)).toReturn("huh");
assertEquals("huh", ml.get(0));
assertEquals("second", ml.get(1));
}
}It works correctly. However, the following idiomatic and functionally similar simplification throws a complicated internal exception in the “spy” method.
import static org.mockito.Mockito.spy;
public class PlaypenTest extends TestCase {
public void testMockito() {
List real = Arrays.asList(new String[] {"first", "second"});
List ml = spy(real);
stub(ml.get(0)).toReturn("huh");
assertEquals("huh", ml.get(0));
assertEquals("second", ml.get(1));
}
}Maybe I’ll get around to using it for something. I’m still not sure.
mockito - Google Code
An interesting article considering potentially conflicting results about how to improve software quality, and drawing some general conclusions.
InfoQ: TDD Opinion: Quality Is a Function of Thought and Reflection, Not Bug Prevention
I find this an interesting contrast to another InfoQ article:
InfoQ: JSR-305: Annotations for Software Defect Detection
For me this is heading toward madness - annotations already have the potential to form a crazy, fragile and mutually incompatible mess around code, and now another proposal to dollop a load more syntactic noise on otherwise simple Java. This seems mostly like a strange, ugly and potentially incomplete attempt at implementing design by contract.
In almost all areas of software development, and especially in test-Driven Development (TDD), testing is vital. In many ways, automated testing by developers is even more valuable. However, as Jay Fields points out, attitudes to, and practices of, testing vary greatly.
Jay Fields’ Thoughts: Immaturity of Developer Testing