(for context: I’m a solid TDD believer and practitioner)
My worry with TDD marketing is that people really get stuck on the “test” word and misunderstand it as “write the kinds of tests you currently write…except before the application code” and that just confuses everyone because the TDD tests are very different from the kinds of unit tests one would typically write. Tests are just a vehicle for the practice and I think they’re used to drive TDD because we typically have infrastructure in place that runs the test code quickly and easily.
Either way, I like the framing that this post gives the practice as a versatile tool with many uses!
That’s an excellent way of describing it! I think you hit the nail on the head - people get tripped up on the “test” part of it.
When I’m “in the zone” with TDD it doesn’t even feel like writing tests at all really, it just becomes an extension of my design or coding process, and the “ceremony” or “separateness” of the tests kind of starts to fall away.
BDD (behavior driven development) kind of moves away from thinking of this as purely a testing practice, at least by using the word “behavior” rather than “test”, but I don’t think many people think of BDD as writing tests first.
I’ve often thought of TDD (and unit testing in general) as kind of like a visual design aid in which instead of a whiteboard or design doc, you visualize the problem by defining your inputs and your expected outputs. I might write another post similar to this one using the “visual learning” concept as a basis for another way of thinking about TDD.
(for context: I’m a solid TDD believer and practitioner)
My worry with TDD marketing is that people really get stuck on the “test” word and misunderstand it as “write the kinds of tests you currently write…except before the application code” and that just confuses everyone because the TDD tests are very different from the kinds of unit tests one would typically write. Tests are just a vehicle for the practice and I think they’re used to drive TDD because we typically have infrastructure in place that runs the test code quickly and easily.
Either way, I like the framing that this post gives the practice as a versatile tool with many uses!
That’s an excellent way of describing it! I think you hit the nail on the head - people get tripped up on the “test” part of it.
When I’m “in the zone” with TDD it doesn’t even feel like writing tests at all really, it just becomes an extension of my design or coding process, and the “ceremony” or “separateness” of the tests kind of starts to fall away.
BDD (behavior driven development) kind of moves away from thinking of this as purely a testing practice, at least by using the word “behavior” rather than “test”, but I don’t think many people think of BDD as writing tests first.
I’ve often thought of TDD (and unit testing in general) as kind of like a visual design aid in which instead of a whiteboard or design doc, you visualize the problem by defining your inputs and your expected outputs. I might write another post similar to this one using the “visual learning” concept as a basis for another way of thinking about TDD.