Evgeny, thanks for sharing these thoughts. I wonder, does this approach (code coverage development) satisfy your own objectives you set in the beginning of the article? Will it allow, for example, “…maintaining code easily and run tests quickly”? Theoretically, you might have high code coverage, but majority of the tests are integration tests and their execution takes hours…And the second question how would you suggest to deal with poor test packs that have high code coverage but semantically not stable, i.e. changing in production code does not break your suite of tests?