Yes, we did have a form of automated unit testing, where all tests that we had written would run with our automated build system. The practice of writing our tests first prior to actually developing production code was something that was done only once in a great while.

Thanks for the generous comment on the post.

Happy coding!
Scott

You said:

I had worked with a team that practiced a modified form of Extreme Programming. In this version, there was no pair programming, there was no test-driven development.

OK, there was no TDD. Was there any automated unit testing?

BTW: nice post. Really liked reading about your experience in applying TDD.

Philip

Philip

Please let me know if I can clarify anything if it doesn’t make sense.

you said: …a modified form of Extreme Programming. In this version, there was no pair programming, there was no test-driven development.

Was there any automated unit testing?

you said: There were user stories, iterative development, refactoring, etc. With this new team I decided that I would give this TDD a try as I was hearing that a big piece of the agile benefit(s) were being missed by not unit testing.

Do you mean by not doing automated unit testing?

Automated testing is an essential part of XP because it is needed to guarantee the key technical premise of XP: that it is possible to experience a flattened cost of change curve. Let me explain with a collage of excerpts from Kent Beck’s Extreme Programming Explained (1st edition):

Traditional approaches to software development are careful to make big decisions early and little decisions later.
XP is an entirely different approach to software development that makes each decision quickly, but backs each decision with automated tests, and that prepares you to improve the design of the software (refactor) when you learn a better way to design it.

The XP approach is not possible if the cost of changing a program rises exponentially over time, a universal assumption of software engineering, but it is possible if the cost of change rises slowly over time, eventually reaching an asymptote.

XP says that with a combination of technology and programming practices, it is possible to experience a curve that is the opposite of the exponential cost of change curve: a flattened cost of change curve.

Here are the practices:

* A simple design, with no extra design elements no ideas that weren’t used yet but were expected to be used in the future.
* Automated tests, so we had confidence we would know if we accidentally changed the existing behavior of the system.
* Lots of practice in modifying the design, so when the time came to change the system, we weren’t too afraid to try it.

With these elements in place—simple design, tests, and an attitude of constant refinement of the design we experience the flattened curve, and so the XP approach to software development becomes viable.

Thank you for commenting. If I remember correctly, there were glimpses of progress early on in the game, probably within a few hours. However, these glimpses were not enough to convince me that what I was doing was helping.

For me, I think the “lights went on” after a week or two when I ended up re-writing some of the code I had written earlier in the project. This was the result of the tests pointing out flaws in the implementation. It was definitely a strange feeling at first. I don’t believe I would have realized the benefits unless this happened.

All I can say is that it was a very liberating experience and I feel fortunate that for some reason I suffered through the pain early on. It would have been very easy to just throw out the whole concept.

Best regards,
Scott

I also really like your description of your “A ha” moment, where you no longer felt like you were just flailing. I am curious to how long it took for you to reach that point.