A Guide to Test Driven Development (TDD) in Flex – Introduction

TDD (Test Driven Development) is a method of writing code that starts with creating tests then goes on to writing the classes afterwards.
I am a big fan and use it whenever I can. It is not appropriate for all types of development but if you organise your code using the model view controller pattern or by using presentation models you can make good use of this technique.

Unit testing in general is a very good habit to get into. Not only does it test the code that you have written but it also demonstrates to other developers what the class is supposed to do and how it supposed to be used. If you combine unit tests with a good Continuous Integration set up then you ensure that other developers don’t accidentally break your code.
Unit tests also help when bug fixing. When I get a bug to fix hopefully the code will have unit tests. If it does I add a test that demonstrates the bug and fails. I then modify the class and make sure that my new test and all the existing tests pass.

TDD goes beyond this and encourages us to write better code. By following the steps that I outline it forces you to think about what the class will do before you start to write it. If the class is doing too much or is too complicated then split it up into more than one class and delegate some of the responsibility to other classes.

TDD forces you to think about the public interface that the class presents to other classes. This helps you think about encapsulation. Classes should NOT make things public just so that you can test them.

All of this leads to writing smaller simpler classes with simple public interfaces that are easier to test. If you write the tests first then you are going to write easily testable code. You should also end up with just enough code. When implementing your class you will write just enough code to make the tests pass and no more.

A common reason for not using unit tests or TDD is that the developer doesn’t have time. I disagree with this. Most of the projects I work on are large and compiling the application and running it takes a long time. Doing this every time you want to test every small code change is slow. I find it much quicker to make sure the logic is correct before I have to run the whole application. Compiling and running a test runner is MUCH quicker than running the whole app.
Unit testing also allows you test edge cases or race conditions that would be hard to re-create in a running application.
On top of these savings tests save a lot of time in the long run. They reduced the number of bugs and encourage you to write code that makes maintenance easier and quicker as well.

During this series of tutorials I will use TDD to help me create a fairly simple component. I will step through how I write code using TDD. This doesn’t necessarily follow all the steps that you are supposed to follow if you are strictly following TDD but it works for me.

During these tutorials I will be referring to the SUT – the System Under Test. This is basically the class that you are testing.

The tutorials will be broken up into the following sections:

• Defining what the SUT does
• Writing our unit tests
• implementing the class

To get started we need to define what our SUT will do.