169: Striking Balance in The Test Suite

Ideas on TDD

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Off Topic: TDD is About Experimentation

Test-Driven Development is an exploration tool. The practice is a discovery tool because it provides an environment for fast experimentation. Thus the fundamental purpose of TDD is to aid in acquiring immediate feedback. By enabling automated byte-sized experiments, TDD ensures that feedback on changes is received. By establishing a process that is not only understandable and flexible but also similar across peers, TDD allows for a more cohesive team. Trying as many examples as possible is necessary to confirm any assumptions about the problem.

TDD has an advantage over other approaches because it allows us to experiment with many solutions for the same problem in less time. Yet, it's important to consider the trade-off of testing only essential application pieces. This trade-off is not worth it, as the business's success depends on being flexible and accommodating to customers' needs.

Business rules are rules or procedures that make or save the business money. Business rules describe the operations, definitions, and constraints that apply to an organization. Business rules define business constraints. Business rules are intended to assert business structure or to control or influence the behavior of the business. Flow is a state of mind where information processing happens, and some writers refer to it as "being in the zone." For programmers, being in the Flow means being able to think about an idea and translate it into code. To achieve this state, one needs to have a clear understanding of the problem and its context. 

Unrelated: Friction-Free Design with TDD

TDD puts evolutionary pressure on a design. TDD pushes a design towards change with every new feature. Testing principles allow for a cost-effective and flexible way to extend a system. Different people have different preferences when it comes to testing. Yet, what's important is that we all feel confident in our ability to code and make changes to the code. Following TDD gives us the certainty that the code can be improved.

When writing code with TDD, we must reevaluate our design if there is excessive friction. The issue isn't whether to use TDD but understanding when each design decision is worthwhile. Applying design ideas without considering the context can result in messy code, whether it passes tests. If the software is meant to evolve with the business, it must adhere to the rules that define it. By enabling automated byte-sized experiments, TDD ensures that feedback on changes is received. By establishing a process that is not only understandable and flexible but also similar across peers, TDD allows for a more cohesive team. 

Current Work: Striking Balance in The Test Suite

While as a beginner, you shouldn’t worry much about what not to test on day one, you better start picking it up by day two. Humans are creatures of habit, and if you start forming bad habits of over-testing early on, it will be hard to shake later. Think of it like this: What’s the cost to prevent a bug?

Thank you for checking out the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. Doing so gives me more time to develop new ideas to share with you.