A few words on design and testing.

My experience with Unit Testing, design for testability and TDD (Test-driven Development) is short; I am no expert, no guru, no ninja, or anything like that. Having said that, I don’t consider myself a total n00b. I really get this designing for testability kinda thing, you know, the Law of Demeter, decoupling, SoC (Separation of concerns), and so on. On my latest projects I have been using this approach to design and develop, and it has completely improved the quality of my work.

By using these philosophies and good practices, not only can one test the hell out of each class but it’s easier to look at a class and know exactly what it does and how it’s intended to collaborate with others. This way, the code is cleaner and easier to understand, and one can know exactly where things are without having to dig too deep into the code or use the debugger to figure out how things work. When a bug comes to light you can easily pinpoint its location because the design tells you exactly who is responsible for what. The beauty of it is that now that you found a bug, you can write a test for it, which should fail, you fix the bug and that should make your test pass. This way, you prevent the bug from resurfacing or at least you are more prepared for it.

Perhaps every developer is different, but for me, it really helps creating an image of all the actions which need to occur for a given feature to work, and who is responsible for each of these actions. In other words, before feeding (insert your favorite editor here) with lines and lines of code I do some good old UML class diagrams and write some Unit Tests for the classes I’m about to write.

I really recommend taking care of the design of your software before you start coding. UML and TDD are very useful design tools which will aid you on this journey of clarity and testability.

More on this to come…