The worst test suites read like word salad after a C++ compiler had a stroke. The best test suites adopt business language.
Write Tests in plain language
🔐 This is an exclusive preview from my next booklet chapter for paid subscribers. I read all feedback you send me. How does it apply to your situation? What challenges are you seeking help with overcoming?
Who are tests for?
We begin this topic carefully. Testing is an open-ended discussion as a general practice. Testing efficiency depends on how tests align with business and team objectives.
The value of a test suite is only ever as good as your ability to express business objectives. Testing automation serves anyone wanting to inspect the business capabilities of your software.
Business objectives are expressed in a mix of business jargon and plain language. When a test passes or fails, there must be no risk of misinterpreting what it means. Write your test name in that language. The test name is the first thing your test-runner sees. Even when the tests run under an automated or AI-assisted suite, its report will be read by a human.
Test passes? It should give you: confidence, certainty, insight, new ideas, a sense of progress.
Test fails? It should tell you: where, what, why, a sense of how difficult it is going to be to fix.
How often do you scratch your head questioning a flaky test’s red or green status?
BDD / Jasmine
XUnit frameworks fail miserably at providing testFunctionTestNameIsErgonomic. Sadly the early 2000’s testing books didn’t age well. They were written and invented in a mix of old Java, C and older .NET versions to assist in dynamic analysis of behavior that compilers couldn’t catch with their type systems.
Keep reading with a 7-day free trial
Subscribe to 🔮 Crafting Tech Teams to keep reading this post and get 7 days of free access to the full post archives.