To test or not to test
Testing is the bedrock of solid software development. It’s not just about squashing bugs, it’s about crafting a foundation that keeps your code dependable, maintainable, and a breeze to work with. From my own experience, I’ve noticed not every developer buys into testing. Some rock a YOLO mindset, thriving on the thrill of tossing bugs into the wild and patching them later, rather than building a sturdy base of tested code. Skip the tests, and you’re flirting with a hulking monolith — devs start piling on new code instead of tweaking what’s there, terrified of shattering some vital piece. Left unchecked, this spirals into an untamable dumpster fire. To me, writing tests feels like a no-brainer, yet I keep running into devs who resist the idea. Here’s a rundown of the most common objections I’ve heard:
Common Objections to Testing (and Counter-Arguments)
"REQUIREMENTS FLIP AND TESTS EXPLODE"
Tests should break when requirements evolve — they’re there to flag when logic no longer aligns with expectations. If the business rules stay put, but you’re still rewriting tests for every new feature, that’s a sign your tests suck, likely because they're overly focused on implementation details instead of the big-picture behavior. The problem isn’t testing itself — it’s how you’re doing it.
"WRITING TESTS TAKES MORE TIME THAN DOWNLOADING WINDOWS UPDATES"
Track your bugs religiously. We often lowball how long bug fixes take, and honest tracking reveals the real cost in time. If your bug-fix rate’s at zero, I’ll eat my words, but I’ve never seen a reliable codebase without solid test coverage. Plus, manual testing during dev? Total time vampire. Automating it speeds things up and makes code friendlier for the next person — no more secret voodoo in one dev’s head. As a manager be careful of rewarding the “bug hero” who swoops in for quick fixes, ignoring the devs churning out stable stuff.
"TESTS ON, BUGS STILL LAUGHING"
Testing’s an art you refine over time. You learng what's absolutely crucial to test and what you can comfortably skip. I’ve seen tests so over-mocked they’re just flexing on a lone if statement in a sea of code. It takes practice - don’t expect gold right out of the gate.
"TESTING'S NOT MY GIG"
Some developers view testing as a QA task, but this separation increases effort . You’re already running the code to check it why not write a test to do that instead of poking it manually? Also, track the times when a ticket comes back with “QA failed,” and you have to restart development and test everything again, manually.
"NO TESTS, NO TOOLS, NO CLUE, NO HOPE"
In startups, speed often trumps quality. Fair enough to get to market, but as a company grows, bugs get pricier. Early on, it’s all about shipping; later, customers demand polish. Without tests, the code balloons, and there’s never a perfect moment to bring in tools or training. Managers, track defects and delivery hiccups. Carve out time for key tests and build team skills gradually - it’s a future-proof investment. Reward stable, tested code, too.
"MANAGEMENT COULDN’T CARE LESS"
They often don’t - until disaster strikes. Devs need to step forward, putting risks in language they get: measure time spent on bugs, note late deliveries, and tie it to financial impact. Management may not comprehend the code’s state, imagining tests cover it or underestimating fixable flaws. If after all they’re unbothered by chaos and you’re driven to fix it, you’re at a crossroads - either suck it up or jump ship. Code quality is a strategic decision - not all prioritize excellence, weighing it as a cost versus a long-term gain.
"TESTS ARE FOR WIMPS, YOLO"
YOLO’s cool if your shop’s a madhouse. Otherwise, I bet you’re just posturing, stacking code like a Jenga tower, chanting “don’t touch it” while it wobbles. Refactoring? What's that?
"MY CODE’S A GOD - TESTS CAN’T TOUCH IT"
Tests? Pfft - those are for peasants, not your celestial genius, right? If you’re really the Michelangelo of coding, maybe I’m wrong, but really? (Track those bugs and prove it.)
"TESTS SUMMON THE CODE KRAKEN"
That's a valid one! Still, I say it’s a risk worth taking. Pro tip: skip testing on a full moon.
How to Prioritize Testing
If you're convinced by my counter-arguments, you might want to dive head-first into blanket-covering your codebase with tests, but hold on. Often, managers push full-on TDD with 100% coverage. That usually doesn’t lead to better-quality code - but neither does 0%. Figuring out this number varies for each codebase and takes judgment, especially if we’re starting from a low point. So, how do we decide what to test and what not?
Focus on Critical Paths
What’s the core functionality? Identify the features or flows users rely on most (e.g. login, checkout). If these break, your app’s dead in the water. Also, follow the money: if your code ties directly to revenue (e.g. payment processing, order fulfillment), test that first. A bug there hurts more than a glitch in the settings page.
Target High-Risk Zones
- Bug-prone code: Look at git history or bug trackers — where do fixes cluster? Test the stuff that’s broken before.
- Complex logic: Prioritize functions with lots of conditionals, loops, or edge cases. Complexity breeds bugs.
- Refactoring candidates: If you plan to rework a module soon, tests give you confidence to make bold changes without breaking things.
Develop Awareness During Coding
With time, you can build a mental map of the codebase, so whenever the opportunity arises you can spot the problematic areas, quick wins and the best targets.
Why Testing is a Must-Have
Documenting Behavior
Tests act like living documentation. They show exactly how your code is supposed to work, making it clear for anyone (including future you) who needs to understand it. No more guessing what a function does - just run the tests.
Confidence in Refactoring
Want to clean up that messy codebase? With a good test suite, you can refactor fearlessly. Tests confirm your changes didn’t break anything, so you’re not holding your breath every time you deploy.
Detect Regressions and Cut Debugging Time
A test suite catches regressions fast - those sneaky bugs that can creep in even when you 're doing only a tiny tweak'.” Instead of spending hours (or days) debugging, you pinpoint the issue in minutes.
Writing Testable Code: The How-To
Testing’s more than tossing assertions around — it’s about crafting code that’s made to be tested. Here’s how to make it happen:
Make Testing a Habit
Start writing tests from day one. It’s a grind that pays off, forcing you to nail design and edge cases early.
Cut Dependencies
Fewer dependencies mean fewer headaches. Reduce reliance on third-party libraries or pesky side effects like logging.
Keep It Simple
Write small, focused functions and use straightforward constructors. Complexity is the enemy of testability — simple code is easier to verify.
Stick to the Law of Demeter
Don’t dig too deep into object structures (e.g. obj.getA().getB().doSomething()). Stick to “tell, don’t ask” to keep your code loosely coupled and testable.
Avoid Hidden Dependencies and Global State
Global variables or sneaky side effects are testing kryptonite. Make dependencies explicit (e.g., pass them in) so your tests can control the environment.
Favour Generic Methods
Write reusable, flexible methods over hyper-specific ones. Generics are easier to test because they’re not tied to one-off scenarios.
Favour Polymorphism Over Conditionals
Swap if/else chains for polymorphic behavior (e.g. interfaces or subclasses). It’s cleaner, more extensible, and lets tests target specific implementations.
Choose Composition Over Inheritance
Inheritance can lock you into rigid hierarchies. Composition gives you flexibility, making it simpler to mock or swap out parts during testing.
Final Thoughts
Testable code isn’t just about passing tests — it pushes you to write better code. You get modular, manageable systems that make sense. Sure, it takes discipline, but the time you save debugging and the confidence you gain refactoring make it worth every second.