1. 4
  1.  

  2. 2

    Yeah, so um… don’t do that in your [modern] codebase. :) A decent team would have code review as SOP, and decent code review(ers) would point out large gaps in test case coverage. (e.g. “We shouldn’t only test positive integer inputs here, but also zero, negative and nil inputs.”)

    1. 2

      What were the odds that I would be able to craft a simple, straightforward example that would crash code that was passing hundreds of tests and was in production for years?

      Higher than you think. Sometimes “straightforward examples” just don’t get hit in normal program runs, such as due to data sanitation happening before it hits that part of system. Other times the errors are so infrequent or low priority that things just don’t get fixed because there’s only so many people and so much time. It might have even been something as simple as the original author getting interrupted and losing focus and forgetting a case.

      It’s not just time pressure which causes people to make mistakes, it could be ego of the code owner handing off the change (“should be easy, just do X” so junior person just does X), overconfidence, inexperience, or unfamiliarity with the code base. You might also see “this feature is a minor thing, and we already have tests” followed by “it passes tests, and tests should already cover this and look ok”.