1st problem - you should be coding such that you can make at least two iterations. It should be perfectly okay to code it once so that you have an idea and then throw it out and do it correctly. If you work in sufficiently small steps, there's barely any time waste plus you save time that you would spend maintaining
2nd problem - Kent Beck's (the guy who "invented" TDD) idea behind TDD was that it should help you be less stressed. If your job is to make a prototype or get something really out the door really fast and you won't lose sleep over it, then there is no need to write tests. TDD is there to enable you.
I am not exactly sure, what you mean with the unit tests, so apologies if I am misunderstanding. I use integration tests in my red-green-refactor loop as well
1st problem - you should be coding such that you can make at least two iterations. It should be perfectly okay to code it once so that you have an idea and then throw it out and do it correctly. If you work in sufficiently small steps, there's barely any time waste plus you save time that you would spend maintaining
2nd problem - Kent Beck's (the guy who "invented" TDD) idea behind TDD was that it should help you be less stressed. If your job is to make a prototype or get something really out the door really fast and you won't lose sleep over it, then there is no need to write tests. TDD is there to enable you.
I am not exactly sure, what you mean with the unit tests, so apologies if I am misunderstanding. I use integration tests in my red-green-refactor loop as well