Testing is a method used for demonstrating that software satisfies its specification. It is a methodology to prevent faults being introduced when maintaining software. In the sixties this was done manually by e.g. labour-intensive debugging. Preventing faults in software with tests gained traction after 1990 historically.
As engineers we are always in search for better and more optimum solutions to our craftsmanship. while there are many alternative ideas around, the mainstream is having a testable software. Having unit tests is increasing the quality of software in many ways:
- Helps us find the bugs earlier
- Provides documentation on how the unit is intended to be used
- Improves design
- Simplifies maintaining and extending features
- It forces your code to be more modular
- Brings up clarity for developers, makes you really understand your code
- Simplifies refactoring
- Simplifies debugging and mostly removing the need of debugging
(coding with relying on debugging is a bad habit)
- Makes collaboration easier and more efficient
- Removes the fear of change
It is also good for planning work if you can trust your code. Even better if you are developing TDD you are adding a lot of unit tests.
So now we got the basics. Having tests is good. We are telling every developer to test their code to increase quality. But the problem is that we don’t have a common definition of how to write testable code. Coming from more traditional coding styles and trying to adapt into unit testing is a delicate process. You need to change your mindset. It is challenging because some of these principles prohibit you using some of the language features.
In these series I will try to cover the principles of writing testable code with some examples.
You can download all the example code from this link.
Here are the chapters;