> It's really bad when doing anything that requires exploration and research I wouldn't say that, I have an counterexample ([1]): It is clear what the refactor

> It's really bad when doing anything that requires exploration and research I wouldn't say that, I have an counterexample ([1]): It is clear what the refactoring (that is to be implemented) should do and how to state that ([2]), but it usually requires exploration and research how to work with the AST and which methods to use. I would even say that TDD is awesome for exploring, researching, for getting a feeling of the problem's context, what to do and what the caveats are, as long as neither of that is required for stating the test itself. Having tests first, you can simply start the debugger, try things out and with hot reloading you can write the code while running the specific test that you want to concentrate on. Visualization tools like [3] can greatly help exploring how to solve and implement the current test while you debug it. [1] https://blog.hediet.de/post/implementing_typescript_refactorings_with_hot_reloading https://blog.hediet.de/post/implementing_typescript_refactor... [2] https://github.com/hediet/hediet-ts-refactoring-lsp/blob/master/language-service-plugin/test/main.test.ts#L32 https://github.com/hediet/hediet-ts-refactoring-lsp/blob/mas... [3] https://marketplace.visualstudio.com/items?itemName=hediet.debug-visualizer https://marketplace.visualstudio.com/items?itemName=hediet.d...