Sarah Mei

Crucially: the portfolio of tests you write changes depending on which of these are most important. Different _mechanics_ come into play.

Which reasons are most important to you, in turn, are different in different places in the codebase, and also shift over time.

When people make statements about test mechanics ("don't use mocks!"), they're really just telling you how they order that list of reasons.

I want more discussions of how various mechanics enable or restrict tests from fulfilling those basic reasons, and fewer blanket statements.

This is NOT a list of what you always get. They're possible outcomes, and you can write tests differently to emphasize different ones.

Imagine a set of tests written with only one goal in mind: preventing regressions. What does that look like?

When I see a codebase primarily covered with top-level integration tests, I know that team sees regression catching as testing's only goal.

@sarahmei also, #4 doesn't ring true for me. Speaking as an ardent long term TDDist I think we always wanted this to be true but it ain't.

@ph1 it's possible to write tests that add nothing to your understanding. It's also possible to write tests that illuminate dark corners.

@ph1 These aren't a list of what you always get; they're possible outcomes, and you can write tests differently to emphasize different ones.

@sarahmei I'd perhaps replace 1 with a more general "validate behavior". I usually first write tests to verify things actually work.

@ph1 Hmm, you're right - this list is more the lasting effects of writing a test. Maybe there's another list of more immediate benefits.

@sarahmei 1 & 3 are independently true, I think 2 & 4 are partially byproducts

@sarahmei @grmpyprogrammer don't forget because they feel pressured to do so by just about any programming blogger ;)

.@SPengilley @sarahmei @grmpyprogrammer if you feel externally pressured to do tests, you haven't been programming long enough. :)