A Revival for Test First, If We Don't Waste It
Using a coding assistant might turn out to be the best thing that has happened to Test-Driven Development (TDD) so far. This is the seventh post in my series about coding with an assistant.
For more than twenty years the objection to TDD was always some version of the same thing. No time. Too much typing. We will add the tests later. The assistant removes that objection. It types the test for you in seconds and it does not get bored doing it. On top of that, the path of least resistance with an assistant now runs straight through the test. I made that case in Fitness Functions for an AI Coding Assistant. To get useful work out of the assistant you have to tell it what done looks like, and a description of done that a machine can check is a test. TDD stops being the disciplined choice and becomes the efficient one.
A small case from the other day. We have our own frontend abstraction in TypeScript for calling the backend. It adds the authentication and context every call needs. A colleague had written a plain fetch to download a file. It added those details correctly, but it went around our convention of taking the call mechanism from a context, and that convention is what lets us drop in a mock and test the component. The plain fetch could not be tested that way. Before, I would have mumbled, filed a tech debt issue, and then taken the same shortcut myself to keep moving. This time I asked the assistant to file the issue, add the missing API, and use it in the component I was working on. The component went back to being testable, and doing it right stopped being the expensive option.
I want to believe a revival of test first is coming. I am not sure it is. This post is me being pessimistic about developers, myself included, and hoping I turn out to be wrong.