Test Driven Development - Think about it!

Over the last few years I've been moving my teams towards Test Driven Development.  If you're not there, you need to be looking at this paradigm.  In essence, the following is what you are shooting for:

1. Write your test.
2. Run your test - the test should fail because the code hasn't been written yet.
3. Create the bare minimum of code that will allow the test to pass.
4. Continue to refactor the code until you are satisfied - is it simple, have you removed any duplication?
5. Repeat - accumulating additional tests until full functionality matches the agreed upon requirements and design criteria.

I've been on this push for a couple of different reasons: 1) The QA Team is spending an inordinate amount of time performing regression tests that should be in the build process; 2) The QA Teams and Development Teams should spend most of their time on new feature/new function testing - not regression testing; 3)  Within the old paradigm that we were following, by the time the development team member became aware of a defect in the code, they had long since moved on to other parts of the code and it was not fresh on the mind.

I've recently spoken with several groups of students - some high school and some at the collegiate level - and the one common theme that I have been impressing on all of these groups is that they need to think about testing first.  That means while doing the design work and prior to any code being written, they should understand how they will test the code and then execute against the plan.

In a separate session. when meeting with some of the instructors - another individual recommended that the instructors should have a base set of tests created that the students will need to execute against their assignments.  The students could do this at any time to get immediate feedback.  If an instructor were to pursue this paradigm within their classrooms, I would encourage them to create a portion of the tests, but force the students to create their own set of tests.

Unless our teams are working on a completely new system - there should exist somewhere in the organization a base set of tests that cover the current functionality.  It may not be extensive, but it's there somewhere.  That's the baseline!  No build of the system should happen without improvements to that baseline with your development team increasing the code coverage with additional unit tests that are then included in the set of regression tests the next time that code is touched.

Let's face it, immediately after the code has been written and the developers focus shifts on to the next task, their ability to maintain the code begins to drift.  I'm not saying they can't maintain it, but that they will need to spend time re familiarizing themselves with the code and then planning how to make the change.  Additionally, you can't guarantee that the next time the code needs to be touched it will be touched by the same developer.  By having these tests complete and in the pool of regression tests, you set an expectation with the developer that they can't claim they are complete with the code until all regression tests are complete and they can prove that they have tested against the new feature/functionality of the application.

Really, when it comes down to it, it's about accountability within the development team.  They are just as responsible for the quality of the code as are the people working the front end of the project - discovery and requirements, design - and those working the back end of the project quality assurance and the user representatives.

If you'd like more information on my background: LinkedIn Profile