Alexei Kovalev I don’t like slow running integration tests… The amount of instability they usually have (or efforts required to make them stable) very much undermine their efficiency. But I like writing tests with very wide coverage (as opposed to the unit tests) and without external dependencies (as opposed to integration tests) — they usually run very fast and also do not lock the design making refactoring simple.

Even 100% coverage doesn’t guarantee that all the scenarios are tested and the code is bug free. The opposite is true though, the coverage less than 100% guarantees that there are untested scenarios. So for the lack of a better metric I’ll continue to use it as a rough indication of sufficiency of tests.

As one of of my colleagues said, “I believe there’s no “one testing way to rule out all problems” and every project, UI or back end, polyfill of library, should be flexible enough to grant quality, whatever it takes to achieve that.” I agree with that and I was provocatively suggesting coverage as a main development driver as something that makes as much sense as TDD (or maybe just a bit more).

But using coverage is very important, as Isaac Schlueter (creator of npm and one of the main contributors to nodejs) wrote: “running tests with coverage changes the way that you think about your programs, and provides much deeper insight.” I can’t agree more, it did change the way I think about code.