Would you like to buy me a ☕️ instead?
In product management, the distinction between output and outcome is critical. Output can be thought of as the immediate results of our efforts—features shipped, tasks completed, and hours logged. Yet, the outcome is what truly drives value: satisfied customers, market growth, and achieving strategic business goals.
When we dive into the world of testing in programming, it’s easy to get caught up in the numbers game—how many tests have we written? What’s our code coverage? However, if we pause and consider the bigger picture, we realize that the true measure of success isn’t the output; it’s the outcome. What’s our end goal with all this testing? It’s not about ticking just another box; it’s about building better software faster.
This shift from output to outcome encourages a more meaningful approach to both product development and testing, ensuring that every effort is aligned with the desired end results.
Shorten Your Feedback Loops, Write Better Software
Now, let’s talk about feedback loops. Tests are our shortcut to knowing if our code is doing its job without manually checking every single time. If you’re just tweaking a minor feature and only need to check it manually in the browser once, maybe you can skip the tests. But let’s be honest, how often is that the case?
For those more intricate features that have us checking and rechecking dozens of times, tests are a no-brainer. Why spend 30 seconds plus the mental cost of context-switching for each manual testing cycle when you could invest five minutes into writing a test that does it for you? It’s about efficiency, not just bug prevention.
The Unit Testing Debate: When Less Might Be More
Theo, in his YouTube reaction video “We Finally Agree On Unit Tests,” reacting to ThePrimeagen, drops some serious wisdom bombs that resonate with this approach:
- At the heart of it, 90% of the time, we’re tackling straightforward problems. If our code is a tangled web of complexity, we’ve missed the mark on crafting clear and efficient solutions. (Unit) tests won’t save us from this mess.
- The essence of testing is to liberate us from the grind of repetitive tasks. If we find ourselves bogged down by the process of writing tests, it’s time to recalibrate. Our tools and processes should streamline test creation, not complicate it.
- When discussing testing methodologies, we must consider the context. Unit tests can be invaluable assets or unnecessary burdens, depending on the situation. When we’re in the thick of exploration and discovery, rigid testing can stifle our progress. It’s about striking a balance—discard what’s unnecessary and embrace tests that accelerate our journey to a solid solution.
When it comes to testing web user interfaces, I see component tests analogous to unit tests. They can be incredibly valuable, but let’s face it—most of our day-to-day web development challenges are pretty straightforward.
Not All Tests Are Created Equal
In the industry, there’s a strong emphasis on unit tests, and while they have their place, let’s not forget about a category of tests that I consider much more valuable when it comes to testing complex web application user interfaces: End-to-End or (what I like to call) Application Tests.
Application Tests mimic real user interactions and can be a game-changer, boosting our confidence in our application—even when the tasks at hand aren’t overly complex.
These behavior-driven tests don’t just check if a piece of code works in isolation; they ensure our application behaves as expected in the wild. That’s a level of assurance that unit tests alone can’t provide.
In conclusion, when we talk about testing, let’s shift our focus from output to outcome. Tests are our allies, designed to speed up our workflow and enhance our software. They should be quick to write, painless to run, and above all, they should make our lives easier. So the next time you sit down to test, ask yourself: is this helping me build better software faster? If the answer is yes, you’re on the right track.