Andrew's ramblings

Test Drive Development (TDD)

Tags: Test Driven Development, Coldfusion

I wanted to talk about TDD, or as some call it Test Driven Design either way I am going to discuss what it is and how a developer can really benefit from it.

I once asked an old collegue whether he was using CFUnit, and the response I got was the same that I seem to hear all so often. it is a waste of time and adds to much overhead to the development. The reality is that it does the reverse. So what is it. By definition, most developers have a form or method to test what they develop. But the biggest problem is that as a developer you can only test the input and output as much as you can. The biggest problem comes when other functions or code starts to interact with some aspects of code and can break the code without you knowing that it has.

TDD has been around for a very long time, and really has gained a lot of ground in the main stream enterprise development communities. But it should not only just apply to large enterprise solutions, and no matter how big or small the project is. All projects can benefit from this methodology, regardless of team size or project size.

In the comming weeks I will go further into depth, but for now here are the main rules that one should adhere to when adopting TDD.

1) Quickly add a test
2) Run all tests and see the new one fail
3) Make a little change
4) Run all tests and seem them succeed
5) Refactor to remove duplication

This may seem to most as excesive, but look at it this way. If you write a test, and refactor and adopt all scenarios with tests you should end up with tests for every line of code. And as I said this may seem excesive, but in the long run the importance is that you will end up with less problems that you would if you didn't develop with a TDD mehodology.

Next time I will go into more detail and steps to write tests and refactor the code.
Tweet