CharlesMaxWood

Gregg Pollack posted this video to the Envy Labs Blog. It’s a terrific example of Test Driven Development. Here is the video and 8 lessons you should learn from it.

1. Performance Katas

Have you ever read a book or watched a presentation and learned something really interesting only to forget it a week or two later? I know that I have. Performance Katas are on the other end of the spectrum. They are exercises designed to help developers practice certain aspects of their chosen development language. I wrote a post last week about Code Katas and a few other sets of programming exercises.

This video was what got interested me to Dave Thomas’ Code Kata’s.

2. Test Driven Development

While I was working at SolutionStream, I worked for a client who insisted on doing everything test first. To me, this meant that I’d write tests and then write the entire portion of code that did everything I wanted it to do. As I matured in TDD, I learned that you actually only write the minimum it takes to make it pass. Corey provides an excellent example of what TDD really means and how it allows you to take your development step by step to make sure that it covers everything you need it to.

3. Change the message or make it pass.

This is a quote from Bryan Liles’ talk at acts_as_conference 2009. Corey demonstrates this in a couple instances.

I found it extremely interesting to think about. It means that you don’t have to make your tests pass on the first try, you just have to solve the problem the test identifies for you and then either solve the next problem it presents to you or write another test because the last one passed.

4. Create helper methods for your tests to keep them dry

As soon as Corey noticed similar structure between two of his tests he wrote a helper method to handle it. Not only is this a good practice for writing tests, but writing code as well. It was very clearly demonstrated how this simplified writing the rest of his tests.

5. Rspec context

Corey’s demonstration of Rspec’s context setup was something I hadn’t seen before. I’ve really enjoyed using Rspec thus far, but the documentation he generated for his module looked extremely handy. The context also provides a nice division in the tests for areas of functionality.

6. Modeling pair programming

There were a couple of points during the presentation where I saw problems as Corey typed them in. It was interesting because it reminded me of what it’s like to pair program. Whenever I’m pairing with someone, they’re usually a few steps ahead of me when I’m programming and I’m usually a few steps ahead of them when they’re programming. See if you can pick out the minor snags Corey runs into while programming.

7. Failures are not bad

This is something that comes with experience with TDD. A failure is not a bad thing. Failures tell you where there is a problem. It’s a signpost of where to go next. A failure indicates that there’s something you can change or fix before the code is released into production.

8. Tests document code

At the last URUG meeting I went to, I was discussing a project a friend of mine was working on with him. He pointed out that he really has no idea what the code base does because there were no tests for it. In the same way, Corey was using the tests to determine what his code was doing. He also used the context to generate documentation for the code.

Overall, this code kata Corey did is something that developers should watch a couple of times to make sure that you pick up on the terrific coding practices demonstrated.

code kata, documentation, helper methods, pair programming, rspec, rspec context, TDD, test driven development, testing, tests