> But a lot of people cast “unit test” as “test for each method on a class” which is too low-level and coupled to the implementation; Those tests suit a projec

> But a lot of people cast “unit test” as “test for each method on a class” which is too low-level and coupled to the implementation; Those tests suit a project that applies the open-closed principle strictly, such as libraries / packages that will rarely be modified directly and will mostly be used by "clients" as their building blocks. They don't suit a spaghetti monolith with dozens of leaky APIs that change on every sprint. The harsh truth is that in the industry you are more likely to work with spaghetti code than with stable packages. "TDD done right" is a pipe dream for the average engineer.