The tests are not exactly driving but safeguarding. So I would argue its not TDD. However, it is a good workflow in its own right that has similarities with TDD. The fast feedback loop makes it extremely valuable.

Hi Emily, It's awesome to see you doing a KZfaq series!! As you walked folks through this, and since you channelled a bit of Bob in there, I was thinking of his Transformation Priority Premise. Your presentation of this kata solves the hard parts by prioritizing which order the tests should go in to have the smoothest progression from no passing through fully passing. A lot of folks go off the rails because they don't really have a sense of in what order they should write the tests. It also made me think of another thing - I friend of mine once reflected my coaching back at me in the most brilliant way - (paraphrasing) "if you are doing TDD, it's harder to test the implementation because it doesn't exist yet, it focuses you on testing across the outcomes." This is another way IMO that approval testing can gain you the same kinds of outcomes as TDD. Anyways, back to TPP, have you thought about test order and some ways to break this down for folks to help them not get trapped into prematurely solving the whole problem.

I recently did a talk about this at work, inspired by your videos. While I won’t argue about the definition of TDD, using approval tests this way provides arguably the same benefits. Early feedback on design, enables refactoring and protects against regressions. Where I work we do lots of mathematical modeling, and a typical challenge is that we don’t know the correct output beforehand, so it’s hard to write the test first. However, once we have a new output, we always have some way of validating it, even if it’s just eyeballing a plot. With approval testing, once the output is validated, we approve it and check it in. Rinse and repeat. This enables us to do almost(?) TDD where we previously might not have had any automated tests at all.

It's TDDish, because it gives you the same benefits but through a different means. I use this method when the output I want is a string, like LaTeX or Markdown. I have a vague notion of what I want, but I can't write it down concretely. So I use the code to help generate the test case. As you said, it's hard to see the benefit in this example, because the output you're really testing is a boolean but your test is comparing strings.

I've been using TDD since 2000. This is TDD. In the small, it's different from what I learned, which was indeed Bob Martin's "rules". By the time you commit, though, it's identical.

I got inspired by this and added an approval test to one of my perl script

This is amazing Emily! I agree that this can still be a kind of TDD! You still have the fast feedback loop. And you have the expected value written beforehand in your head. Than you verify if the result matched and approve if yes. I think this qualifies it! Oh, you are from Gothenburg, right? Maybe we can call it the Gothenburg-School of TDD? ;)

It makes me feel uncomfortable that the correctness of your code only relies on you comparing the spec (the sketch) and the test output. In a project I worked on, the spec was a large table of numbers elaborated by a business analyst, and he actually made occasional mistakes Thanks to a robust set of unit tests we (the devs) could point which edge case the analyst had missed. So I would not identify acceptance testing (ATDD or BDD ?) and TDD. Unit testing gives me more confidence because I have a set of tiny tests, each of them validating a single business rule whereas acceptance testing yields a single test (or a smaller group of tests) for all (or many) of them at a time