Chapter 1: The Basics of Business Rules Coverage

In the realm of software development, most professionals are familiar with the idea of code coverage; however, shifting your focus to a different concept may be beneficial.

Business rules represented by DifussionBee. What does code coverage entail?

Code coverage is a fundamental metric used to assess quality and determine how effectively the code has been tested. It is calculated by executing tests that identify which sections of the code were executed and which were not. The outcome is a percentage indicating the extent of code execution.

While code coverage is easy to measure and is often automated within most development pipelines, I previously cautioned against its potential pitfalls in my second Medium article.

The Myth of 100% Code Coverage

Some argue that aiming for 100% code coverage is unrealistic and prohibitively costly. Many developers aim to reduce this target...

Beyond serving as a quality assessment tool, code coverage has other vital roles. In the right context, it can highlight parts of the code that may be redundant, aiding in lowering maintenance costs. It can also reveal gaps in business rules, as developers often consider numerous scenarios and inadvertently discover unanticipated situations. Unfortunately, these situations may go unreported as developers often choose to code solutions directly. Analyzing code coverage can bring these unexpected scenarios to light. However, enforcing strict code coverage can be detrimental.

My Experiment with Enforcing Minimum Code Quality

Tools like SonarQube exist to monitor and enforce baseline quality standards; but do they genuinely provide value?

The challenge lies in the fact that while achieving high code coverage is relatively straightforward, crafting meaningful tests is not. A passing test that merely executes a code section does not guarantee its functionality. The difficulty in writing quality tests often leads developers to produce superficial tests that merely execute the code without ensuring its effectiveness.

Crafting Reliable Tests

If tests are intended to confirm the correctness of production code, how can we ensure the reliability of these tests?

Additionally, I propose another experiment inspired by a tweet from Allen Holub:

He suggests an automated test generator capable of executing code and increasing code coverage to 80%. This doesn't rely on advanced AI but rather on executing random code during tests to boost coverage. While I have doubts about consistently achieving that 80%, the variations may differ from application to application. Nonetheless, it could be an insightful experiment that exposes the consequences of poor practices commonly seen in software development.

The Relationship Between Business Objectives and Code Coverage

The connection between business aims and code coverage is nuanced. Code coverage assesses the code itself rather than the application or its alignment with business goals. While the application is built from code, the code often includes details that hold significance only for developers. Consequently, tests may be biased toward the code, neglecting the critical areas vital for business.

Developers excel at focusing on code but may overlook business objectives, leading to tests that prioritize code artifacts over essential business rules. As a result, it is possible to achieve 80% code coverage while failing to cover significant business rule implementations. Thus, having extensive code coverage does not necessarily equate to application reliability.

Shifting Focus to Business Rules Coverage

What if we redirected our focus from code to the business rules themselves? The concept is simple: rather than measuring code coverage, we should measure the execution of business rules in tests.

Although this shift in focus is straightforward, measurement is more complex. The challenges stem from the need to test edge cases and the often implicit nature of business rules, which are frequently documented in various formats that are hard to automate. Translating these rules from natural language into machine-readable formats is essential for automation.

Embracing Business Rules Coverage

Fortunately, these challenges have been addressed, notably through Behavior-Driven Development (BDD). BDD allows for writing acceptance criteria in a human-readable format that machines can execute. By documenting business rules as BDD scenarios, we can begin tracking them.

We can first count all scenarios and then tally those that have been automated. The ratio of automated scenarios to total scenarios will yield the business rules coverage percentage.

This resulting figure will provide insight, with minimal uncertainty, into the application's reliability and its alignment with business objectives.

Further Exploration of Business Rule Coverage

For those interested in delving deeper into business rule coverage and its practical implementation, I highly recommend Greg Wright's article:

Why is Nobody Talking About Business Rule Coverage?

How business rule coverage can transform software development.

Conclusion

While code coverage is undoubtedly useful, it offers limited insight into an application's operational effectiveness. In contrast, business rules coverage delivers direct information about an application's reliability concerning business objectives.

So, would you prefer achieving 80% code coverage, or 80% business rules coverage?

Thank you for reading. For more insights on testing strategies, check out my article:

Do Not Test Everything Right Away

Often, we mistakenly believe that complete testing is necessary for quality assurance.

You might also be interested in my most popular stories on Medium:

My Most Viewed Stories

And my Bio.

The first video titled "What are Business Rules?" explores the fundamental aspects of business rules and their significance in software development.

The second video titled "How to Complete the Business Rules Template" provides guidance on effectively documenting business rules in a structured manner.