@nixCraft good comments explain if it does that on purpose, so you know if your "fix" to make it safer will actually break something else

(or to be boring and get away from the image, good comments answer "what were they even trying to *do* here?!", because The Code only tells you what they *actually* did)

@EndlessMason @LionsPhil @nixCraft No, the unit tests explain if it's *always* done it, or if it's only just started.

Unit tests can be just as buggy as code, so you still need comments (or good naming) to explain the intent of *those*.

Your contention here is that there are tests that pass for a behaviour that's either not deliberate or is not correct.

If your test suite is like that you have bigger problems than somebody turning the gun and getting shot... you don't even know if the gun can do a get shot...

You're talking about a test suite that passes when they do get shot, or tests that pass when the gun jams.

@imsop @LionsPhil @nixCraft

@EndlessMason @LionsPhil @nixCraft
Yes. I'm talking about the real world, not a TDD textbook.

If you make a change and a test fails, is it a) because the test perfectly covers a requirement you hadn't accounted for; b) because the test implicitly covers the behaviour that you were intending to change; or c) because the test was just badly written, and relied on implementation details that don't actually matter?

Of course, comments and names can *also* be wrong, but they give you an extra clue as to what some previous developer *thought* both the code and the test were doing.