> ... I practice “weak TDD”, which just means “writing tests before code, in short feedback cycles”. This is sometimes derogatively referred to as “test-first”.

> ... I practice “weak TDD”, which just means “writing tests before code, in short feedback cycles”. This is sometimes derogatively referred to as “test-first”. Strong TDD follows a much stricter “red-green-refactor” cycle: > 1. Write a minimal failing test. > 2. Write the minimum code possible to pass the test. > 3. Refactor everything without introducing new behavior. > The emphasis is on minimality. In its purest form we have Kent Beck’s test && commit || reset (TCR): if the minimal code doesn’t pass, erase all changes and start over. An example would be helpful here. In fact, there's only a single example in the entire article. That's part of the problem with TDD and criticisms of it. General discussions leave too much to the imagination and biases from past experience. Give me an example (pick any language - it doesn't matter), and now we can talk about something interesting. You have a much better chance of changing my mind and I have a much better chance of changing yours. The example in the article (quick sort) is interesting, but it's not clear how it would apply to different kinds of functions. The author uses "property testing" to assert that a sorted list's members are of ascending value. The author contrasts this with the alleged TDD approach of picking specific lists with specific features. It's not clear how this approach would translate to a different kind of function (say, a boolean result). Nor is it clear what the actual difference is because in both cases specific lists are being chosen.