Vladimir Khorikov’s article titled “You are naming your tests wrong!” delves into the intricacies of test naming conventions, specifically critiquing the [MethodUnderTest]_[Scenario]_[ExpectedResult] format. He suggests that this convention often leads developers to focus overly on implementation details rather than the system’s overarching behavior. By advocating the use of plain English phrases in test names, he believes tests can be more expressive, offering better clarity even to those outside the programming realm.
To enrich this discussion, I want to shed light on two fundamental concepts in software testing: verification and validation.
Verification asks, “Are we building the product right?” ensuring that the code is correctly implemented and functions as intended. On the flip side, validation inquires, “Are we building the right product?” confirming that the software aligns with user or business needs.
Software testing can be visualized as a gradient, shifting from verification-centric tests, such as unit tests that revolve around code specifics, to broader validation-centric tests like acceptance tests, which are rooted in user expectations.
Considering unit tests are primarily verification-focused, their innate alignment with code details is both expected and beneficial. While it’s essential for tests, especially those leaning towards validation, to be universally comprehensible, unit tests, due to their nature, are bound to be technical. Aiming for them to be understandable for non-domain experts could compromise their main purpose – that is rigorous verification.
However, Khorikov’s perspective is not without exceptions. He acknowledges that utility classes, which are void of business rules, can adopt the conventional naming strategy, emphasizing the distance between these classes and the domain of validation.
Conclusion
While Khorikov makes a compelling case for the value of readability and descriptiveness in test naming, it’s evident that the choice of naming convention can be influenced by the nature of the test and its underlying objectives. There’s merit in preserving method specificity for unit tests, but it’s equally essential to balance technical depth with clarity, particularly when non-developers are involved. The ideal approach might be a hybrid of conventions, tailored to the context in which they’re used.
Leave a Reply