> Why not? If it works it works. Not everyone is concerned with receiving the award for best programmer.
Ok, that clarifies things: programmers who avoid reading the docs to guess, or follow the "Google search, stack overflow, paste in the first answer" cycle are mediocre programmers. If they don't want to be good programmers (which what the article is talking about), they can keep doing what they're doing.
> If you are not capturing "why" in your tests, what are you testing, exactly?
You can't capture why in code. Your tests are a demonstration of the "what."
- A programmer who applies a laundry list of what they do to determine who makes for a "best" programmer, who doesn't guess themselves, is likely to exclude anyone who does.
- A business person is apt to consider someone who successfully delivers a product quickly by using someone else's code among the "best".
> You can't capture why in code.
Then you can't capture it in natural language either, making this whole thing moot. But I disagree with that idea.
> Your tests are a demonstration of the "what."
You have a point that some testing frameworks carve out a special declaration for "example" tests that are marked for inclusion in generated API docs. There might be a time and place for that kind of documentation, but that isn't the kind of testing I was thinking of. That isn't representative of the vast majority of the tests you will write. If it is, you're doing something wrong – or at very least aren't being fair to those who will consume your tests later.
In my laundry list, concern for the next guy is what separates the "best" programmers from the mediocre. But I understand why your laundry list differs.
> Why not? If it works it works. Not everyone is concerned with receiving the award for best programmer.
Ok, that clarifies things: programmers who avoid reading the docs to guess, or follow the "Google search, stack overflow, paste in the first answer" cycle are mediocre programmers. If they don't want to be good programmers (which what the article is talking about), they can keep doing what they're doing.
> If you are not capturing "why" in your tests, what are you testing, exactly?
You can't capture why in code. Your tests are a demonstration of the "what."