Approval Testing vs TDD

Añadido: 2026-05-16

[00:00:00]Approval testing. It's a technique that's very useful in legacy code. You can use a an approval testing framework to do characterization testing, where you basically pin down the behavior of legacy code. And I use it for that a lot. But you can also use approval tests to drive TDD. And it's it's not obvious because of course the thing with an approval test is that the assertion is not defined up front. So it's not canon TDD. You define the the tests just as the arrange and the acts, or the given and the when. And then the the actual part that checks what happens isn't defined until the implementation is finished. Or not finished, or at least better. So you get a TDD process where you you you get a failing test, but you you just get this diff to say, "Well, this is what you're actually getting when you run the test. Is that Is that what you wanted?" So it's not canon TDD where you you define up front what you expect. But I find that it works because I guess maybe I'm just cuz I'm used to the rhythm of TDD, you you can still get this very nice feedback cycle going where you're making small steps, and the the output you're seeing in the diff is looking better and better. And each time you approve it, you've got green and you can refactor. But it's it's a different kind of TDD cuz in in in classic TDD you get this test list and you're kind of crossing things off. And you're getting more and more tests. In an approval test you you you got we'll just like work with one test and and iterate on that one until it looks good, basically. What do you think? Is Is I've been trying to convince you here this is TDD. I'm afraid I was I I still disagree. So I am very very grateful to you for introducing me to approval tests in the first place many years ago. And I didn't get it at first, but but now I do and I find them extremely valuable and I recommend them almost everywhere for characterization testing. But I confess that I think that you're skipping over an important part of the conversation in your description there. So I was talking to Brad Dave Thomas a little while ago, and he said he doesn't always write tests anymore. And that's because he's done so much TDD that TDD has taught him how to design, so he can design pretty well without the tests. And I think you're doing the same thing. I think that absolutely. If that's working for you, I I can't critique it. It's you working for you. It's good. But for me, when I'm exploring, the problem that I have is that the an approval test is always based on my solution. It's based on the output from my solution. So, sure, I can look at the results of the output from my solution, but I could do that in other ways other than approval tests and decide whether I like them or not. And that might be useful input, but it doesn't seem like it's the same thing as TDD to me.