Quality of software is the single most important factor in deciding whether a customer buys your product or not. The product could look very pretty and run very fast, but if it fails to achieve the user’s goals in the best manner possible every single time, you will be left with more than a few unhappy users. The best known way to ensure high quality software today is by testing it before it is released.
Why Testable Code?
It does follow logically, doesn’t it. Quality software is very important. The best way to get quality software is to test it. And the best way to test code is to ensure that it is testable. In this series of posts, i will try and explore what i mean by testable code and will make an attempt to elucidate how code can be made more testable, more maintainable and achieve the holy grail of software – how your code can be ‘clean‘.
The evils on non-testable code are many. And they get worse over time. If a few modules are badly written, testing them will be extremely difficult and hence, there will be no tests or insufficient tests. Over time, mode code could be written in these modules and gradually lead to lesser and lesser reliable code, fewer tests and a fear for refactoring. This situation looks like a decay curve until we reach a point where the only options are to rewrite entire libraries or ditch the project completely.
Is this related to Design Patterns?
Not quite. I will talk about, allude to or refer to certain design patterns – at this point, it might be necessary to point out that the definition of ‘design patterns’ for this discussion is restricted to the ones defined by the GoF. However, some of the principles that will be discussed in this series has very little to do with which design pattern you choose to use. Most importantly, just because your code is based on one or more design patterns does not automatically make it testable.
Is this a series on TDD?
Well, yes and no. I will not talk about Test Driven Development though i would strongly advocate it. There are hundreds of blogs and renowned authors talking about it and i might not add too much value by doing it here. Most of the techniques and coding principles that i will discuss in this series will be more effective and easier to follow if the tests are written first. Having said that, the benefits can be reaped even if the tests are written later. The only requirement is that you believe in the value of testing and write the tests.
Will this be about JUnit/Fitnesse/JDave/JBehave/etc?
No. This is not a series on tools and nor is it on testing. This is a series on coding. Coding that will aid testing. This will talk about various principles in coding that will aid in producing code that is inherently easy to test. This will also talk about pitfalls and will provide examples of code that one should avoid writing.
Now that the scope and purpose of this series has been established, let us begin our journey.