Long time back, the focus was on testing classes, its methods in isolation which got termed as unit tests.

People were obsessed with 100% coverage. That all resulted in a lot of brittle test code which used to break every now and then as and when class contracts got changed. Resulted in lots of waste.

Move forward and people recognized it and understood problem with class based testing with mocks.

The focus is not on the functionality (behavior) instead is on implementation (classes). A change in implementation causes change in tests.

James Coplien wrote seminal articles on "Why most unit testing is waste" and people experimented with this idea as well. Cope also mentioned TDD is not the right way to design and provided better alternatives.

In the light of all this how relevant unit tests are and how relevant TDD is?

Let's learn all that and more.

• Why exactly test coverage is the wrong metric to focus in test automation
• The notion of test pyramid and reverse test pyramid. Why more focus on the functional test automation is wrong
• Why the practice of writing unit tests focused around classes and methods introduces lots of waste
• Is test automation the panacea of quality or that''s just the beginning
• What's the better alternate which provides the relevant ROI without wasting too much time automating stuff.