>A test might have prevented the typo for the second argument to calculateLine().
If the compiler didn't puke on it in the definition, or if that was the line in the test it would just be a bug in the test. Of course that all depends on the time honored development tradition of running a hastily written online comment in production. As far as the assumption I'm knocking tests for their utility at testing, I'm not, I'm knocking their utility as documentation.
> As far as the assumption I'm knocking tests for their utility at testing, I'm not, I'm knocking their utility as documentation.
Except you're not doing that, either. You're knocking the utility of a poorly-written tests-as-documentation test versus the utility of some hypothetically better written documentation.
But if your developers are going to write such uninformative tests-as-documentation, there's no reason to believe their documentation-as-documentation would be any better, so all you're really doing is making the uncontroversial assertion that poorly written documentation sucks.
Making the more relevant and informative comparison of well-written documentation-as-documentation to well-written tests-as-documentation, the tests-as-documentation have the inescapable bonus of being incapable of falling out of sync with the code.
In my, and a lot of other people's, experience, textual documentation tends to become an outdated liability almost as soon as it is written.
> slope, yintercept = calculateLine(x1, y2, x2, y2)
It is, in fact, a place where a test would be quite helpful. A test might have prevented the typo for the second argument to calculateLine().