> I also wasn't aware that "unit" referred to an isolated test, not to the SUT. I'm with you. That claim is unsubstantiated. It seems to trace to the belief th

> I also wasn't aware that "unit" referred to an isolated test, not to the SUT. I'm with you. That claim is unsubstantiated. It seems to trace to the belief that the first unit tests were XUnit family, thus were SUnit for Scheme. But Kent Beck made it pretty clear that SUnit "units" were classes. https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm https://web.archive.org/web/20150315073817/http://www.xprogr... There were unit tests before that. SUnit took its name from common parlance, not vice versa. It was a strange naming convention, given that the unit testing framework could be used to test anything and not just units. Much like the slightly older Test Anything Protocol (TAP) could. > [on unit tests] This does lead to a lot of work maintaining them whenever the implementation changes, but this is a necessary chore because of the value they provide. I disagree. Unit tests can still be behavioral. Then they change whenever the behavior changes. They should still work with a mere implementation change. > This is why I still think that the traditional test pyramid is the best model to follow. I'll disagree a little with that, too. I think a newer test pyramid that uses contract testing to verify integrations is better. The notion of contract tests is much newer than the pyramids and, properly applied, can speed up feedback by orders of magnitude while also cutting debugging time and maintenance by orders of magnitude. On that front, I love what Pact is doing and would like to see more competition in the area. Hottest thing in testing since Cypress/Playwright . . . https://pact.io https://pact.io