In the first part of this writing I showed the basics about test driven design. Of course, it was my understanding and experience of doing TDD, but I still think that many of you learned something new for themselves.

In the previous part we finished with development of domain resolver, which tells us list of domains and registered user names in these domains. The design was driven by tests, created before the actual code. The tests allowed us to see the picture from outside and define minimal usable interface for domain resolver component. This time, we will create a dialog box component which will be talking to domain resolver implementation to read data for its drop-down lists without actually knowing the source. The dialog will also do basic validation of entry and displaying of warning messages.

Read more

Branching is a very useful concept in sources tracking. It allows to isolate some version of sources and continue with experimental development, bug fixing and anything else, which is better kept away from the main trunk. It’s generally simple to do branching when you have just decided to, but what if you are already two weeks (month or year) away from the version you wish to branch from?

Read more

Writing tests is usually simple task. When you write tests ahead of code and even ahead of design it becomes really trivial task. Having all tests at hand even before you start coding specific functionality guaranties that you will (a) spend minimum time, (b) implement what’s really necessary, (c) have all documentation and tests ready, (d) sleep well, knowing that you can give the product away in the middle of the night as it’s already tested to be fool proof.

Read more