Test Driven Development

It is a buzzword that has been around for ages now, and when I first heard it I thought it was more hassle than it was worth. That was because management had decided to introduce it into an already established project. That doesn’t work. It is better to start to implement it when a project starts.

Ideally you have a design which separates the “business logic” from the interface. For example, with WebcomiX, the whole Comic and navigation and refreshing was in a stand alone library. It was easy to add unit tests to check that …

  • A GenericComic loaded its config data correctly.
  • The ComicCollection loaded a lot of GenericComics correctly.
  • The StatusRefresher refreshed the favourite GenericComics correctly.

If every on screen button just calls a method on one of your models, then it is easy to simulate the app in use without actually having an app yet. You do this iteratively as well. You start with your basic classes and get them working in tests. Then you add the more complex ones and get them working in tests. You know at any time that if the unit tests start failing then you have broken something. It is much easier to debug tests than it is to debug a full application.

Of course, if you change how something works, you have to change the tests as well. Don’t let tests stay broken for too long or you might as well forget about them. If they are not passing then they aren’t doing their job.

Leave a comment

Your email address will not be published. Required fields are marked *