47 ms·

The article illustrates what happens when you have inexperienced or poor developers following a management guideline. To see how 100% coverage testing can lead

by pg314 9y ago

The article illustrates what happens when you have inexperienced or poor developers following a management guideline. To see how 100% coverage testing can lead to great results, have a look at the SQLite project [1]. In my experience, getting to 100% takes a bit of effort. But once you get there it has the advantage that you have a big incentive to keep it there. There is no way to rationalise that a new function doesn't need testing, because that would mess up the coverage. Going from 85% to 84% coverage is much easier to rationalise. And of course 100% coverage doesn't mean that there are no bugs, but x% coverage means that 100-x% of the code is not even run by the tests. Do you really want your users to be the first ones to execute the code? As an anecdote, in one project where I set the goal of 100% coverage, there was a bug in literally the last uncovered statement before getting to 100%. [1] https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html

thehardsphere 9y ago
Doesn't what you're writing actually influence whether 100% coverage is a worthy goal or not? I mean, SQLite is a good example of something where 100% coverage would actually be useful, because it tries to maintain compatibility with the SQL spec and with Postgres (largely because Postgres complies with the spec). Testing that 100% makes a lot of sense. Suppose you're instead doing something very UX/UI driven. Why bother trying to cover that 100% with automated tests, when change is going to be driven by the whim and fancy of anyone who sits down in front of it?
- pg314 9y ago
  > Doesn't what you're writing actually influence whether 100% coverage is a worthy goal or not? Yes, absolutely. > Suppose you're instead doing something very UX/UI driven. Why bother trying to cover that 100% with automated tests, when change is going to be driven by the whim and fancy of anyone who sits down in front of it? It might make perfect sense from a business standpoint to have no tests at all.

by pg314 9y ago

thehardsphere 9y ago

Doesn't what you're writing actually influence whether 100% coverage is a worthy goal or not? I mean, SQLite is a good example of something where 100% coverage would actually be useful, because it tries to maintain compatibility with the SQL spec and with Postgres (largely because Postgres complies with the spec). Testing that 100% makes a lot of sense. Suppose you're instead doing something very UX/UI driven. Why bother trying to cover that 100% with automated tests, when change is going to be driven by the whim and fancy of anyone who sits down in front of it?

pg314 9y ago
> Doesn't what you're writing actually influence whether 100% coverage is a worthy goal or not? Yes, absolutely. > Suppose you're instead doing something very UX/UI driven. Why bother trying to cover that 100% with automated tests, when change is going to be driven by the whim and fancy of anyone who sits down in front of it? It might make perfect sense from a business standpoint to have no tests at all.