In a conversation elsewhere, I mention @markmandel and ColdSpring which got me to thinking about a podcast I guest appeared on in the early 00's... where I spoke about Test Driven Design and unit tests in general... So... I just wanted to throw out there.... Yell from a cliff-top and if something comes back - great - and if it doesn't - oh well I guess it was a duck's quack... Test driven-design is NOT about "anally" writing tests. It's most definitely NOT about getting a % of coverage, either. For me: It is only about code-confidence. Did the Bug fix... / Did the new feature... / Did the rewrite.... • Actually do what I am expecting it to do? • Break something I never thought would have a touch-point with my change.

Actually do what I am expecting it to do?

Also emphatically making it clear what it's supposed to do:

it("does the thing that I am stating right here that it's supposed to do", ...)

@Adam Cameron Totally agree the test makes clear what the code should be successfully completing. Personally, I am not militant about the difference between TDD and BDD... as Engineering staff - it always about what code is needed for "this" required end-result. If it is a "user-story" or a technical document that is the source of the "this" - I am not fussed, I am STILL about make a test that will prove the requested result is achieved, My personal love for it though - is has the created solution impacted something elsewhere? Does adding a new argument to function "A" - break other stuff - that I didn't think about? If it does - that's still a great outcome - because I can fix that new issue, now. -before the code is deployed and customers are "screwed over" because of something the Engineering team produced.