As some have noted, I’m not actually against tests. Quite the contrary - I’ve been practicing TDD since 2013. My approach to software is driving emergent design by TDD, initially via an E2E test, then via fast, integrative acceptance tests that exercise features while faking IO. I do write unit tests for very specific and pure pieces of software that embody a business domain, such as algorithms or validations.
What I abhor is compulsively writing mockist unit tests for all classes or functions with the goal of satisfying some coverage metrics. These are hurting you thrice: you waste time writing them and maintaining them; you get a false sense of confidence because you have “full coverage”; and when trying to refactor, they hold you back.
As some have noted, I’m not actually against tests. Quite the contrary - I’ve been practicing TDD since 2013. My approach to software is driving emergent design by TDD, initially via an E2E test, then via fast, integrative acceptance tests that exercise features while faking IO. I do write unit tests for very specific and pure pieces of software that embody a business domain, such as algorithms or validations.
What I abhor is compulsively writing mockist unit tests for all classes or functions with the goal of satisfying some coverage metrics. These are hurting you thrice: you waste time writing them and maintaining them; you get a false sense of confidence because you have “full coverage”; and when trying to refactor, they hold you back.
You can read more about my approach here: https://www.shaiyallin.com/post/fake-don-t-mock