debuggable

Hi folks! Since Test-Driven-Development (TDD) is probably t h e way to develop in a world of failing software, I thought I could write an introduction to it today. It will be broken up into a series of parts (planned are three parts), which I will release on a day-to-day basis.

The goal of Test-Driven-Development

Clean code that works is the goal of Test-Driven-Development. Clean code that works is a worthwhile goal for a whole bunch of reasons:

• It gives you a chance to learn the lessons the code has to teach you. If you only hack together the first thing you can think of, you won't have the chance to think of a second, better thing.
• It improves the lives of the users of your software. Keep in mind that if you don't test your software, your users will..
• It is a predictable way to develop. You know when you are finished without worries about a long bug trail.
• It lets your teammates count on you, and you on them.
• It just feels good to see the green bar (i.e. all tests passing).

However, how do we get to clean code that works, with all the external factors that seem to be preventing us from doing so? We drive development with automated tests - which is ultimately called Test-Driven-Development.

What do we do in Test-Driven-Development?

We write code only if an existing automated test has failed. We eliminate duplication (check for The DRY-principle).

These two rules / behaviors introduce complex technical implications. To make them work we have to:

• ..design dynamically, with running and working code providing feedback between decisions.
• We must write our own tests, because we cannot wait 20 times a day for a colleague to write our tests.
• Our development environment must provide rapid response to small changes.
• Our designs must consist of encapsulated components in order to make testing of each of those easy. This is very i mportant and very difficult to achieve in existing environments.

The TDD-mantra

Red - Green - Refactor, according to Kent Beck, author of Test-Driven-Development by Example, is the TDD-mantra. Red means a test failed, green means you make the test work by writing code that satisfies the test and refactor...you use refactoring to make the code as simple and reusable as possible.

Social benefits of Test-Driven-Development

• If you can avoid long bugtrails, then quality assurance (QA) work can be proactive instead of reactive.
• If you can avoid long bug trails, managers can actually manage and plan the project and are able to involve your customers in day-to-day development.
• If clean code that works can be written really fast, planning of programming teams can be made in day-to-day cycles instead of week-to-week or even month-to-month. making software is going to get a lot more profitable for your company.
• If there are no long bug trails, we have shippable software everyday. We can provide our customers with a fresh update everyday with new functionality, making all people involved very happy.

Conclusion

The concept is rather simple, but why would a highly-qualified systems engineer take on small steps in programming - each step so simple that it is plain crazy? What does test-driven-development look like? We will see in the second part of this introduction, which will contain a code sample, too. :)