[hdi]

Somewhat interesting but calling an old idea something catchy isn't really revolutionary.

The article makes a lot of assumptions like "In practice, most agree as most projects set the lower bound for coverage to around 80%". Most projects where, which industry, who are these 80% that agree? This is just taken out of thin air in this case. It might be true but should we take the author's word for it?

  There are also some psychological arguments. For 
  example, if you value unit-testability, you would prefer 
  a program design that is easier to test than a design 
  that is harder to test but is otherwise better, because 
  you know that you’ll spend a lot more time writing tests.

This is very subjective without examples. The opposite argument can also be made that code which is easier to test is sometimes better. It felt like reading a collection of quotes and articles by other people.

I think TDD, unit, integration and E2E testing works. How much of which to apply is entirely project and industry specific and it's up to teams to decide what testing strategy works best for them.

[LoSboccacc]

"The outlook for the effectiveness of testing used by itself is bleak. Jones points out that a combination of unit testing, functional testing, and system testing often results in a cumulative defect detection of less than 60 percent, which is usually inadequate for production software."

https://medium.com/@TuckerConnelly/94-gems-from-code-complet...

personally I like write some cursory unit test because it ensures the code logic is correctly decoupled from data retrieval, but most of my unit tests are written from user reports, as part of a large no regression suite.