TDD is a trade-off: it slows you done in the now but it saves you time in the future. I'm not a TDD guy I am a DDT Guy -> development driven testing guy.
I write my components / modules (prototypes) and than I write test to improve them. -> first i build it, than i test the "expected" cases and than i think about it outside of the integrated context and try to break it (generative testing).
every function or class has to be as deterministic as possible (I ignore language implementation flaws).
which is reduction of side effects, in turn it is usefully to reduce cyclomatic complexity , as well as other complexities (for example scalar parameter instead of objects if possible) -> which just means reduce the amount of possible different results/behaviours of a function/method/class and reduction of dependencies of it.
explaining this in detail .... would lead to far .... in general TDD is a good thing like almost all architectural approaches ....
.... if you never did TDD I highly recommend it because it lets you reflect upon your implementation. If you find out that it imperes your productivity to much you could define core functionalities that need to have a certain coverage and others with lesser coverage to keep a balance between time spent on implementing and time spent on writing / refactoring tests.