This is nuanced, but I try for tests that ensure the business rules (or product features) of the code are being exercised without enforcing specific implementat

This is nuanced, but I try for tests that ensure the business rules (or product features) of the code are being exercised without enforcing specific implementation or style. Sometimes that does mean being highly specific, like when you are conforming to standards or specifications or providing a contract like an API used by third parties, but other times you don’t care how the sausage is made you just need to ensure sausage is getting made. I don’t actually know how the article approached this but again in my own experience, when code is written without testing in mind from the beginning and you just go wild adding them later you instead get tests that enforce very specific coding styles, tests that enforce that the dependency graph is immutable, that internal data formats must never change, etc. If you can add tests without intimately understanding the business reason the code exists you’re more likely writing tests that just lock in implementation. This type of testing also means that every imaginable change will break dozens of tests and puts people in the mindset of just updating the test to pass instead of considering it a real problem because the tests stop giving meaningful information when they fail because literally everything you do will cause a slew of failures. That’s helpful in knowing the blast radius of your change but it multiplies the cost of change instead of reducing it.