In this Areopa webinar, Xavi Ametller Serrat, technical coach at Sunweb and a former Microsoft colleague of host Luc van Vugt, makes the case that every test is a bet: you trade time now for information later, and like any bet, it can pay off or not. Moderated by Luc van Vugt, the session works through the criteria that make a test worth writing, the models Xavi uses to decide when to stop testing, and the technical practices that shift the odds in your favor.
Where the idea comes from
Xavi traces the “tests are bets” framing back to Douglas Hubbard’s book How to Measure Anything, which argues that everything we do in life is a bet. Mapping that idea onto testing gave him a way to reason about three recurring questions: why do we test in the first place, how much should we test, and when do we stop?
📖 Reference: How to Measure Anything: Finding the Value of Intangibles in Business by Douglas W. Hubbard — the book that inspired the “everything is a bet” framing used throughout this talk.
He also shares a personal anecdote: during a Microsoft interview with a director of test, he was asked to write a function and then its tests. When he admitted he never knew when to stop testing, the interviewer’s answer stuck with him — it depends on whether you’re still finding bugs. That “it depends” is the starting point for the rest of the talk.
The value of a test
Before deciding whether a test is worth creating, Xavi asks a framing question: if you write a test for code with no bugs, that nobody will ever refactor, that nobody reads, and that no one uses — what is that test worth? In most contexts, close to zero. Value only appears once a test defends something real.
From there he lays out a taxonomy of what increases and decreases a test’s value:
- Increases value: the value defended (bugs found or prevented, criticality of the feature, usage of the feature, how closely it mimics real user behavior, how easily it pinpoints a bug when it breaks), how many times it executes, whether it supports refactoring, and whether the feature keeps evolving.
- Decreases value: the time required to create and execute it, its fragility (maintenance cost, breaking when it shouldn’t), and overlap with other tests that already cover the same ground.
- An open question: cognitive load. A test can reduce cognitive load by helping you understand a domain, or increase it if it’s verbose or misleading — Xavi leaves this one as a question mark rather than a fixed rule.
He calls out one anti-pattern directly: he has seen a ten-line test in production that ends in assert(true, true). It looked like coverage but actively misled the team into thinking business logic was protected when it wasn’t — a test with negative value.
Automation, refactoring, and feedback timing
Several of the value criteria map cleanly onto concrete practices. A manual test delivers value once, at the moment you run it; an automated test in CI keeps delivering value continuously, for close to the same cost.
Two other timing effects matter:
- Refactoring: a test’s value spikes whenever it enables you to change code with confidence — and that spike can happen more than once over a feature’s lifetime.
- TDD versus test-after: if you write the test first, you start reaping its benefits immediately, even while it’s still red. Writing tests after the code means the code ships without that feedback loop for however long it takes to add the tests.
- Leading versus lagging information: a test that catches a problem before a merge or deploy (leading) is worth more than one that only tells you after the problem is already in production (lagging), because you get the same information sooner.
When to test: a value-versus-effort model
Xavi’s central model plots expected net value on one axis against effort on the other. Tests that need little effort and defend a lot of value are the easy calls. Tests that would cost a lot but return little value are equally easy to skip. The interesting decisions live in between, where teams draw a threshold: past a certain amount of effort, even a genuinely valuable test isn’t worth it right now.
That threshold is not fixed. Xavi lists six factors that move it around for a given person or team: skillset (experienced testers perceive less effort for the same test), project type (a volatile startup context favors smaller bets), risk aversion, mood, recent findings (a string of production bugs lowers the bar for testing more), and architectural enablers (some codebases make testing cheap, others make it expensive).
Because every person on a team can be drawing that line in a different place, Xavi recommends making it an explicit conversation — not just an individual gut check — so a team can agree on where its own threshold sits.
When to stop testing
Following the same model, you stop testing when no remaining candidate test is expected to fall in the “worth it” zone. That can happen for different reasons: other tests already cover the ground (overlap reduces the marginal value of one more test), the remaining tests would cost too much for the value they’d add, or — the most common real-world reason, in Xavi’s experience — you simply run out of time.
He frames this as a lever you can pull deliberately: if you want more tests to land in the “worth it” zone, either reduce the effort a test requires or increase the value it defends. Practices like small increments, readable test names and assertions, test doubles for slow dependencies, canary releases, A/B testing, and observability all work by shifting a test from the red zone into the green one.
No tests, test after, or TDD
Xavi puts the three approaches side by side. No tests means no extra work but also no value. Test-after can surface design problems, but the tests are constrained by a solution that’s already built, and you’re not reaping any refactoring or feedback-loop benefit until they’re written days later. With TDD, the test is created with no constraints, value starts accruing as early as possible, refactoring is supported the whole time, and the risk of writing a test nobody needed is lower because you write only what the next step requires.
📖 Related reading: Automated Testing in Microsoft Dynamics 365 Business Central, Second Edition by Luc van Vugt — the webinar’s moderator wrote this book on applying automated testing and TDD to Business Central, and it’s the discussion that led to inviting Xavi onto the show.
From pyramid to other shapes
Xavi also applies his value model to the classic testing pyramid. The pyramid shape made sense when integration and end-to-end tests were flaky and slow, and tooling for techniques like test doubles was less mature — under those conditions, higher-level tests carried less value per unit of effort. In environments where integration tests now run in milliseconds, he sees the shape shift: fewer unit tests, and a much larger band of integration tests, because those tests are both cheap to run and closer to real user behavior.
📖 Docs: On the Diverse and Fantastical Shapes of Testing by Martin Fowler — a deeper look at why the traditional test pyramid isn’t the only valid shape for a test suite, echoing the pyramid-to-diamond shift shown in this webinar.
Measuring the outcome of your bets
Since the value of a test is genuinely uncertain up front, Xavi closes by suggesting proxy metrics teams can track after the fact: bugs prevented, refactors completed, execution time, feature usage or revenue, time to fix a test when it breaks, and the number of fragile tests in the suite. If those numbers show your testing bets are paying off, double down. If they aren’t, that’s the signal to change strategy.
During Q&A, Xavi fields a Business Central-specific question about whether an assert(true, true) placed after an expected error is legitimate. He’s upfront that he doesn’t know Business Central well enough to answer for that platform specifically, but from his own testing infrastructure — where tests can wait for an expected exception — he would avoid it and instead make the intent explicit in the test’s name.
Follow the presenter: Xavi Ametller Serrat shares more of his thinking on testing and technical coaching at myowncommonsense.com.
This post was drafted with AI assistance based on the webinar transcript and video content.