You can. In a way, writing tests first is all about exploring. You're only specifying what you're trying to achieve in the next little while. The test is a device to tell you when you've achieved it. Then you move to the next step. What you're trying to do overall still evolves.

There is a tradeoff. You end up with a longer program that does the same thing - that's bad. On the other hand it works better, and you're likelier to know if you break something - that's good. People argue about whether the bad exceeds the good or vice versa, but surely that can't be answered all one way or the other.

My experience is that this style of programming is well suited for the OO environments that it emerged from. OO object graphs get complex very quickly and you need a device for managing side effects (i.e. unexpected breakage). Unit tests, specifically TDD, are the best currently known device for that. But to me a better approach is to program functionally in a way that eschews (most) side effects and to test one's code by evaluating expressions in a REPL. That gives most of the benefits of unit testing in a much lighter-weight form. I still write the occasional unit test, but only in targeted places where the code has to do something tricky and I want to keep a record of good examples. All I do in that case is put the expressions I've been playing with in the REPL into a function somewhere.