Recently I had the pleasure of giving a talk at the Canberra Java Users Group on the topic 'Real Developers Don't Need Unit Tests':

"Unit testing, and Test-Driven Development in particular, is a vital but neglected art. Proper TDD don't just test code: your tests are executable requirements that tell the story of your application, clarify your design, document your code and help track your progress. They help you find bugs fast, and fix them with confidence. If Real programmers don't need unit tests, they sure make life easier for the rest of us!"

I've posed the slides for this presentation in this article.

(If you have any trouble viewing this presentation, you can also download it here.)

Test Driven Development (TDD), as well as related techniques like Behaviour-Driven Development and Acceptance Test-Driven Development are growing in popularity among developers, as both empirical evidence and research point to its effectiveness.

If you are interested in learning more about Test Driven Development and Behaviour Driven Development, I'll be running the 'Testing and Test-Driven Development for Java Developers' Course soon in Sydney (20-21 May), Wellington (27-28 May), Auckland (3-4 June) and Canberra (date to be announced soon).

Tags See All Tags Add New Tag...

Please Enter New Tags Separated By Comma's
  Or Close

Agile  Automated Testing  BDD  EasyB  Humour  JUnit  TDD 

TrackBack URI for this entry

Comments (7)

Subscribe to this comment's feed

Great presentation but ...
written by Yishai, May 14, 2010

It is such a shame that the grid was done as a series of dots (on the implementation side). Unfortunately it took a great example of TDD/BDD that is small enough for a presentation (and they are hard to find) and made it into a toy example. The biggest problem I have reaching skeptics is the notion that you can do this for real in a real application with real dependencies.

Loved the Chuck Norris reference, though.

• 
• +0
• 
• 

Good point
written by John Ferguson Smart, May 14, 2010

This example is actually a simplified form of a kata I do in coding dojos and training sessions - the full version uses an array of enums, which is much more realistic.

• 
• +0
• 
• 

...
written by Kerflyn, May 17, 2010

Nice presentation!

I think there is a kind of developer that we can call Chuck Norris guy: sort of sceptical veteran developer, who doesn't believe that TDD is also made for them.

Have you succeeded in convincing such developers?

• 
• +0
• 
• 

Pairing sometimes works
written by John Ferguson Smart, May 27, 2010

Thanks,

TDD needs to be experienced to be appreciated, and preferably experienced alongside an experienced TDD practitioner.That's why pair-programming works so well in teaching TDD practices. It sounds simple on paper, but there is a lot of know-how behind the scenes to get it right. But I've taught TDD to ex-COBOL developers with success - nothing is impossible.

• 
• +0
• 
• 

TDD - Fascist Agile
written by MikeCI, June 17, 2010

To me, TDD is to rigid for developers and it sometimes restricts the scope. I appreciate that testing throughout is a good idea, but agile with CI is a better combination that TDD. If I was a developer using TDD I'd feel pretty oppress IMO.

• 
• +0
• 
• 

look more prospects
written by Unit testing, July 31, 2010

Indeed the TDD and Behavior Driven modules has been getting much popular among the new developers but that's not done, i means the new generation developers must not restrict themselves and must look out for some more synchronized modules to get the better efficiency in development.

• 
• +0
• 
• 

...
written by Rob Sang, May 18, 2011

I think there are TDD die-hards who can benefit from this presentation almost as much as the sceptics! One of the perceptions many people have about test driven development is that you must follow a rigid unit test model, where every method is tested individually an in isolation. While this is a good rule of thumb, knowing when you can break it is just as important or you start finding you have tests that tell you nothing and you become frustrated at the amount of time spent writing pointless tests and blame the TDD process for it.

For example, when developing a web service using some framework it is more valuable to create tests that simulate a response to the request URI than it is to call the implementing methods directly. Because you are using a test to express the actual requirement of the application (responding to the request URI) rather than simply testing a method call with an artificial set of parameters.

• 
• +0
• 
• 

Name

Email

Title

Comment

smaller | bigger

I have read and agree to the Terms of Usage.

Add Comment Preview