Monthly Archives: February 2025

Unit Testing and Testable Code

Unit testing is a fundamental practice in software development, ensuring that individual units of code work as expected. However, the real challenge often lies in writing code that is easy to test. Poorly designed, untestable code can complicate unit testing and introduce expensive complexity. In this blog post, we’ll explore the importance of writing testable code, the common pitfalls that make code hard to test, and the benefits of adopting testable coding practices.

The Significance of Unit Testing

Unit testing involves verifying the behavior of a small portion of an application independently from other parts. A typical unit test follows the Arrange-Act-Assert (AAA) pattern: initializing the system under test, applying a stimulus, and observing the resulting behavior. The goal is to ensure that the code behaves as expected and meets the specified requirements.

However, the ease of writing unit tests is significantly influenced by the design of the code. Code that is tightly coupled, non-deterministic, or dependent on mutable global state is inherently difficult to test. Writing testable code is not only about making testing less troublesome but also about creating robust and maintainable software.

Common Pitfalls in Writing Testable Code

Several factors can make code challenging to test, including:

Tight Coupling: Code that is tightly coupled to specific implementations or data sources is difficult to isolate for testing. Decoupling concerns and introducing clear seams between components can enhance testability.
Non-Deterministic Behavior: Code that depends on mutable global state or external factors (e.g., current system time) can produce different results in different environments, complicating testing. Making code deterministic by injecting dependencies can address this issue.
Side Effects: Methods that produce side effects (e.g., interacting with hardware or external systems) are hard to test in isolation. Employing techniques like Dependency Injection or using higher-order functions can help in decoupling and testing such code.

Benefits of Testable Code

Adopting testable coding practices offers several benefits:

Improved Code Quality: Testable code is typically well-structured, modular, and easier to understand. This leads to higher code quality and reduces the likelihood of bugs.
Easier Maintenance: Code that is easy to test is also easier to maintain. Changes can be made with confidence, knowing that unit tests will catch any regressions.
Faster Development: With a robust suite of unit tests, developers can iterate quickly and confidently, reducing the time spent on manual testing and debugging.
Enhanced Collaboration: Clear and testable code promotes better collaboration among team members, as the intent and behavior of the code are easier to comprehend.

Conclusion

Writing testable code is a crucial aspect of software development that extends beyond the realm of testing. It encompasses good design principles, decoupling, and the elimination of non-deterministic behavior and side effects. By focusing on writing testable code, developers can create software that is not only easier to test but also more robust, maintainable, and reliable. Embracing these practices ultimately leads to higher quality software and more efficient development processes.

All of this comes from the link below:

https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

From the blog CS@Worcester – aRomeoDev by aromeo4f978d012d4 and used with permission of the author. All other rights reserved by the author.

Reflections on Apprenticeship Patterns

While reading parts of the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye, there were a couple points that stood out to me when reading and comparing to my own experiences and knowledge.

An important point brought up by the book in the first chapter is how understanding the logic behind why things are done allows people to adapt to unfamiliar problems. Knowing the “spirit of the rule” allows for people to create new rules as needed. This is a point I personally feel strongly about. Knowing what to do is, really, only an issue of understanding instructions. Having a knowledge of the reasoning behind different practices allows you to apply that understanding to other problems.

Programming is a great example of this. It’s easy enough to follow a guide on writing code to follow some specific function, however, good developers will put effort into understanding how the code works, and will be able to replicate what they know later, or apply it to different situations. Someone who only knows the specific steps to writing the code doesn’t understand how it works, and most likely won’t be able to apply their experience outside of that specific use-case.

Another interesting point that I personally hadn’t considered was that apprenticeship in software development is much better approached as a mindset, rather than a formal form of schooling. The book describes that newcomers will have to “create their own opportunities for learning” in the working environments they find themselves in. I’ve understood that it’s important to have a desire to learn more than what may be expected, but the perspective of creating your own learning experiences, outside of more standardized curriculums but within the same environment was interesting.

This point also carries over into the beginning of chapter 3, where one of the authors describes how after connecting with other Perl developers, he was impressed not just by their knowledge, but by the speed at which they were still learning. Symbolically, the stacks of certificates and qualifications would become buried under book printouts and notes; the desire to learn more taking precedence over hard skills and qualifications that one can accumulate.

Both points culminate in the idea that being a great developer doesn’t mean having countless certifications or even being able to write code well. This is a good foundation, and great software developers usually fall into this category, but what makes them great is the understanding that there is more to learn and the desire to expand their knowledge and experience that sets them apart from the pack.

References:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns Guidance for the Aspiring Software Craftsman Dave H. Hoover Aut; Adewale Oshineye Aut. O’Reilly, 2014.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Software Craftsmanship

Hello!

I’ve had a bit of assigned reading to do for my capstone course, ans as such, I thought it would go the way of most readings of that ilk; incredibly dry and ungodly boring. But surprisingly I had a pretty good time with Apprenticeship Patterns by Dave Hoover and Adewale Oshineye.

The text captures something that I find to be incredibly important to the process of becoming a career programmer, the ability to be flexible. Much of my time spent learning to program has consisted of how to do things, but never why or when we should do them. Sometimes it feels like I have a fairly full toolbox, but I don’t have the required knowledge to apply my tools in ways they weren’t explained to me in. I’ll admit, this is more of a personal failing I feel, but the point still stands.

Chapter 1 and the introductory paragraphs to Chapter 4 really stood out to me the most, as Chapter 1 goes into detail about what it means to be a craftsman, and an apprentice. It highlights the experiences one might go through, and what one might expect to get out of an apprenticeship, but the most compelling out of that chapter was the focus on the need to continue learning. In order to be a good apprentice, and get anything meaningful out of the experience, it takes a want to learn how to become a master, and the willingness to continue to developing your craft, and focusing on how you can improve your mindset and workflow. Chapter 4 stood out to me with it’s anecdote about Dave’s experience with certifications, and his discarding of them as he learned from a group of Perl hackers. Not only was it quite amusing, it highlights ths importance of a flexible mindset. None of us are ever done learning, and in order to ever become a master, you cannot be satisfied with jist maintaining the status quo.

Overall I found the selected chapters to be genuinely pretty inspiring, and it put into perspective where my head is at in terms of my software development journey, and how I might go about improving them. This might be optimistic, but this book might end up being one I read in my off time, a rare feat for an assigned reading of this nature.