Earlier this month I finished The Clean Coder: A Code of Conduct for Professional Programmers by Robert Cecil Martin which contained a lot of great practical advice for professional programmers including knowing when to say no, how and when to ask for help, and the three parts to making a commitment. The parts I found most valuable were the sections on testing.
Martin states it is the responsibility of all professional Programmers to test their code and to write code in such a way that it is easy to test.
"automate your tests. Write unit tests that you can execute on a moment's notice, and run those tests as often as you can."
He goes further to suggest that every line of code should have a test and if it's hard to write test for your code then it should be written in such a way that it is easy to test. One way of achieving this would be to write tests before you write your code. This approach aligns with the principles of TDD or Test Driven Development.
"The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test."
While following a TDD approach may take time to get accustomed to, I do see the benefits in the long run. It will force you to write code that is a lot more flexible and you'll also feel less concerned about making changes to code.
"Professional developers are so certain of their code and tests that they are maddeningly casual about making random, opportunistic changes. They'll change the name of a class, on a whim. They'll notice a long-ish method while reading through a module and repartition it as a matter of course. They'll transform a switch statement into polymorphic deployment, or collapse an inheritance hierarchy into a chain-of-command. In short, they treat software the way a sculptor treats clay they continuously shape and mold it."
"This is one of the most powerful benefits of TDD. When you have a suite of tests that you trust, then you lose all fear of making changes."
Typically the last thing I'd want to do is make changes to code that works. After meeting a requirement I'm usually moving onto the next issue or bug but the thought of continuously shaping and improving code after a feature has been implemented was something I never considered. I can see how having good test coverage in place would give piece of mind when attempting to improve code that was already written.
In addition to unit testing, Martin discusses how, when done correctly, acceptance testing written in conjunction with key stakeholders can be a great tool to greatly reduce requirements ambiguity.
"The purpose of acceptance tests is communication, clarity, and precision. By agreeing to them, the developers, stakeholders, and testers all understand what the plan for the system behavior is. Achieving this kind of clarity is the responsibility of all parties. Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built."
After finishing the The Clean Coder I see how writing tests can be beneficial and I'm more inclined to seek opportunities to use them on future projects.