I’m back in the saddle after having taking a couple of weeks off the Internet.

This week we open with a pair of posts around TDD. First up—Scott Miller of Atomic Objects ran a simple experiment: Faster, better, cheaper! TDD wins in a simple experiment and then earlier this year Mike (GeePaw) Hill wrote: How TDD and Pairing Increase Production, a good explanation as to why it works.

Xavier Quesada Allue aka Mr Visual offers Build a taskboard in 10 steps.

Not a blog post but a useful tool: Sonar from Codehaus may be a way of measuring some (but not all) of your technical debt.

Dean Leffingwell uses Little’s Law, Queuing Theory, and Starbucks to show us why large backlogs are not Agile: An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility.

Anyone who has taken Agile Training from me has heard my remarks about team size. Johanna Rothman gives us “Ideal” Team Size and Ratios—I’m with her. If you have more than 9–10 people on a team, you will get separate subteams forming. On the subject of how many testers/writers does a team need, I like to start with one of each and add developers until they’re at capacity.

Richard Lawrence is chugging away and creating new versions of Cuke4Nuke—a version of cucumber that allows you write your step definitions in .NET: Screencast: Testing Web Applications in .NET with Cuke4Nuke and WatiN.

Michael Dubkaov shows us why it’s a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?

Be Sociable, Share!

• 

Two weeks ago I gave an introductory tutorial on “From Code Smells to Unit Tests” (pdf) at Agile Tour Toronto (thanks to the organizers for a great conference). The slides presented an introduction to Technical Debt, SOLID Principles, The Sea of Complexity, Basic Code Smells, Refactoring and Unit Testing Basics, and Good Practices, Bad Practices. As usual, the slides were only taste of what was said. In the session, two elements didn’t work: First, I wasn’t expecting to have to explain SOLID Principles—I was caught off guard and was ill prepared. Second, the pair Refactoring Demo tanked. The plan was to invite audience members up to refactor Martin Fowler’s Movie Example (git hub browseable, zip file) and then they would make small improvements five minutes at a time.The goal was to help people integrate what we had already covered in the seminar by doing it live. There has to be another way of providing an integration event. Basically, I would need to give the audience a way for experiencing refactoring for themselves.

Please try the Movie Example (git hub browseable, zip file) and see how far you can get with some simple refactorings.

References:

• The Art of Unit Testing: with Examples in .NET (Amazon.ca) – Roy Osherove (.NET and soon a Java version)
• Refactoring: Improving the Design of Existing Code (Amazon.ca) – Martin Fowler
• Refactoring to Patterns (Amazon.ca) – Joshua Kerievsky
• xUnit Test Patterns: Refactoring Test Code (Amazon.ca) – Gerard Meszaros
• Pragmatic Unit Testing in C# with NUnit(Amazon.ca) – Andy Hunt and Dave Thomas
• Pragmatic Unit Testing in Java with JUnit (Amazon.ca) – Andy Hunt and Dave Thomas

BTW David Koontz did the hard work of typing in Martin Fowler’s Movie sample – I just modernized it (Java 1.2 –> 1.6).

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Be Sociable, Share!

• 

Eons ago I promised a blog posting on TDD Adoptions strategy. Well, the posting grew and grew and grew (can you tell I read a lot of kids books?) and along the way morphed into something bigger. In the end, I decided this article needed a wider audience, so I published it on InfoQ. Here’s the blurb:

Making TDD Stick: Problems and Solutions for Adopters

Teams in large organizations still struggle to adopt TDD. In this article Mark Levison shares problems he uncovered when he surveyed teams, and his own strategy to introduce TDD into an organization.

Be Sociable, Share!

• 

Last week a colleague asked for my help finding better unit test tools for Java Script. He’s done some digging on the state of the art with JavaScript unit tests and finds the whole lot wanting. His discoveries:

Read More…

Be Sociable, Share!

• 

A few weeks ago I ran my first Coding Dojo/Randori and while the participants learned from the session there had been a few key flaws:

• The problem was too big
• The problem was in a domain that was unfamiliar to everyone
• The facilitator (me) participated too much Ouch. It was true.

This week we ran a second session and had a much better time. The key to success – pick a smaller problem and let people struggle for a good long time before making suggestions. In addition remind them frequently to ask the audience for help.

This week’s problem:

Score a bowling game, (credit to Bob Martin and Ron Jeffries for the idea) based on the following rules:

• A single bowling game consists of ten frames.
• For each frame, a bowler is allowed a maximum of two rolls to knock down all ten pins
• When a Strike is thrown, the current frame is finished
• Scoring:
  • 0-9 pins knocked down: score the number of pins
  • Spare: 10 + number of pins knocked down by the next throw
  • Strike: 10 + number of pins knocked down by the next two throws.

Effectively this means the ball after a Spare is counted twice – once for the spare and once for the strike. With Strikes the next two balls are counted twice.

Read More…

Be Sociable, Share!

• 

During last weeks TDD Randori session I was asked, what are the advantages of TDD. Here is my short list:

• Writing tests first require you to really consider what you want from the code
• Short feedback loop
• Creates a detailed specification
• Reduced time in rework
• Less time spent in the debugger and when it is required you usually get closer to problem quickly
• Tells you whether your last change (or refactoring) has broken previously working code
• Allows the design to evolve and adapt to your changing understanding of the problem.

Read More…

Be Sociable, Share!

• 

We’re ran out first TDD Randori session at lunch today (approx 15 attendees). I was inspired by Dave Nicolette’s session at Agile 2008 and used the Danilo Santo’s paper on their Brazilian Coding Dojo as a guide.

In a Randori we work as a group trying to solve a small problem using TDD:

• There is one computer with the video output projected on a screen so all participants can see it.
• Coding is done at the single computer by a pair of developers.
• One half of the pair switches out every 5 or 10 minutes.
• The pair on the keyboard should continuously explain what they are doing.
• The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
• The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
• The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
• The pair will use TDD (Test-Driven Development).

I picked the problem based on a complaint I’ve heard from people after many of the TDD classes: “the examples are too trivial and don’t speak to real world problems. I also hear that we don’t enough chance to practice TDD”

Read More…

Be Sociable, Share!

• 

Scruffy Looking Cat Herder (aka Jacob Proffitt) recently wrote Test Driven Development considered harmful. Jacob is writing about why he believes that TDD zealots have caused people to skip unit testing altogether. I allege that Jacob is missing the boat here.

The gist of Jacob’s hypothesis has five points which I summarize:

1. Unit testing provides benefits when used regularly.
2. Ensuring that developers write unit tests is the prime benefit of test driven development.
3. Most unit test advocates are also TDD proponents.
4. Looking for information on Unit Testing? You’re most likely to find a piece encouraging you to test first.
5. Many developers skip Unit Testing altogether because TDD seemed too hard or too much of a change.

Read More…

Be Sociable, Share!

•