4 ms·

The tests today are a way of documenting the developer's expectations (in an executable test) so that you can extend, refactor and delete code in the future wit

The tests today are a way of documenting the developer's expectations (in an executable test) so that you can extend, refactor and delete code in the future without the 'edit and pray' method. And bug hunting time is massively reduced because the bug broke the test suite 10 minutes after being introduced as opposed to 2 weeks later in production. I can't document this, but many software projects fail or are forced into rewrites and rescues. That never happens when you have high code coverage. Has any rescue team ever come into a project and gone 'Well, the test suite is in excellent shape, so this shouldn't be that hard'? That's what I believe, but many products won't have a huge payoff for unit-testing every method. Most of my code coverage is more like automated QA tests through Cucumber / Capybara / Selenium in Ruby.

jbarciauskas 16y ago
You prefaced this with "I can't document this" but the statement that "[software project failures] never happen when you have high code coverage" seems outlandish, I'm certain there are thousands of projects failing right now with 80%+ code coverage due to requirements documentation that doesn't match the user's expectations and developers writing trivial rather than intelligent unit tests.
- Tamerlin 16y ago
  I've witnessed that a number of times -- at one company I worked with, we had a team of 30 people disabled even though all of the unit tests worked fine. Someone had inserted something into some shared code (that with even marginally competent engineering would not have shared) that rendered the entire application stack inoperable. I think it was a monkeypatch (Ruby on Rails), so it was VERY hard to detect.