Maybe this is unique to the field that I work in, but I can pretty safely say that if our organization didn't strive to maintain 60%-80% unit test coverage at a

Maybe this is unique to the field that I work in, but I can pretty safely say that if our organization didn't strive to maintain 60%-80% unit test coverage at any given time, we'd have been sunk a long time ago. We don't "ship" a product. We're a humanoid robotics research laboratory, we have a fairly large and old codebase for what we do (~1MLOC of Java, plus a whole big whack of C++ for JNI), and since we neither have a customer nor an OSS community then we make no guarantees about our API nor do we frequently generate stable, frozen binary releases. As such, the code is constantly being refactored and evolving; especially our numerical based stuff; things like physics, controls, etc. (we use an in-house simulation environment that one of our PI's created while he was in grad school, so even stuff like the 3D engine or the simulator data viz GUI's can change at any given moment). I realize that this is entirely anecdotal and highly specific to what we do, but without high coverage and solid CI (We use a self-hosted Bamboo instance with nightly and every-commit builds), our code would be in complete and utter disarray. The build routinely breaks a dozen times a day when one of the control theory guys checks in a parameter tweak to our state estimator or introduces a new component to one of our modular controllers (we have test suites that actually run headless versions of our sims and mathematically verify the walking behavior). I guess my point is that, as is the case with anything in programming, choose the right tool for the job. Evaluate what you're doing, what your goals are, the nature of your code-base, and decide (as is brushed over in the source article) whether or not the opportunity cost is worth it. For us, we'd be up shit creek if we didn't have high coverage.