Writing Testable Code

For this week’s blog I decided to dive a bit deeper into writing testable code because I think it is a valuable skill. While searching for blogs that discuss this topic I found “TDD: Writing Testable Code” by Eric Elliott. In this blog, Elliott explains the importance of writing testable code barriers to writing testable code, and different tips to keep in mind to write testable code. 

The first thing he touches on is how a good quality process is essential to continuous delivery. One of the most important principles, he mentions, is the separation of concerns because “simplifies complexity and enhances the overall quality of your work”.

In the overview about testable code, he explains that achieving testable “allows for more efficient and effective identification of defects, ensuring higher quality and reliability”. The key characteristics of testable code are modularity (when code is organized into discrete units), clarity (code that is easily comprehensible), and independence (when code can be tested in isolation).One of the barriers of writing testable code that Elliott describes is tight coupling in code. The coupling in code is the instance where changing one part of the code can heavily impact or even break the functionality of another part in the code. If one part is changed there can be a chain reaction of bugs in various other parts of the code. Right coupling can be caused by parent class dependencies, shared mutable states, concrete class dependencies, event chains, state shape dependencies, control dependencies or temporal coupling. He explains that to write testable code you must reduce the forms of tight coupling mentioned because it makes testing easier and promotes a “more sustainable and scalable codebase”. This is why testable code and maintainable code are the same thing. 

Later he explains the test first vs test after approaches. The test first approach is the test driven development approach where tests are written before the code. The benefits include better developer experience and clearer requirements and design. The test after approach is where the tests are written after the implementation which leads to a probability of biased tests and reduced code coverage.

One of the last sections provided is about the separation of concerns which a  design principle for programs into distinct sections that  addresses separate concerns”. This principle is important because it allows independent testing and allows developers to isolate problems more effectively in addition to allowing the ability to make changes without unintended consequences. He describes that he likes to isolate into 3 distinct sections business and state logic (the core logic of the application), user interface, and I/O and effects (the part of the application that interacts with the database).

I think this source was well organized and easy to follow. It made the text easy to understand and provided great advice for writing testable code. I think the last section about how he likes to isolate the sections was especially helpful and I will keep it in mind for the future.