TDD is a paradigm in which we write tests before implementation. In doing so, our tests end up informing and affecting the design of our implementation and its interface. By doing this, we begin to see tests as not only a form of documentation but a form of specification. Via our tests, we can designate how we wish something to work, writing assertions as if the functionality existed, and then we can iteratively build out the implementation such that all of our tests eventually pass.
To illustrate TDD, let's imagine that we wish to implement a word-counting function. Before implementing it, we can begin to write some assertions about how we wish for it to work:
assert(
wordCount('Lemonade and chocolate') === 3,
'"Lemonade and chocolate" contains 3 words'
);
assert(
wordCount('Never-ending long-term') === 2...
