It's also great with TDD if you have decent coverage and want to maintain decent coverage.
One thing I dislike about TDD is I sometimes think better in code than use cases. And stuff like mocks etc take far longer to write than a 5 line fix. Say, I have a repo where it takes variable from source A when X happens, and source B when Y happens.
Now I can do reverse TDD. I write the code first. I highlight my code and tell Cursor to write the tests. I tag all the classes and models and other things that I want Cursor to mock. It writes the test, the tests pass, green. Then I stage the code that I wrote, and those tests should fail, red. It also finds all the dumb things I missed out on like imports.
So there, I have a pair programmer that writes the 300 lines of tests while I write the 5 lines of functional code, no worries about hallucinations and all.
>And stuff like mocks etc take far longer to write than a 5 line fix
If you test from the outside in and build up a library of functional and realistic fakes then over time then this gets quicker and easier.
Ideally I think people shouldnt use mock objects at all, ever - only fakes of varying realism at the edge of the project, populated with realistic data.
One reason for doing TDD is that it compels you to match a realistic test with a realistic scenario. I tend to find people lose that when they do test after, and they instead lock the test in to the current behavior of the code instead. This is not just tedious work, it's also harmful.
Really this. It’s been great for me to dive into an unknown area with a new library from scratch.
Explanations of code work relatively well for smaller chunks of code.
When files get larger, I get more of a miss rate/bad suggestions unless I start tightening the scope.