I tend to be pretty good at TDD when the task at hand is "easy", when I know what I'm doing and don't need to experiment much, basically doing things I've done before.
When I'm working on stuff that may or may not work (trial and error) I get very frustrated with TDD and feel it's just slowing me down in my ability to prove a concept. Of course I will always go back and write some tests, but that's far from being TDD.
I wonder how people handle these situations? Really curious :)
I spike a lot (i.e., write code without tests) until I have an elegant design figured out. Strict TDD would then have you scrap that solution and re-write it with tests, but you may just want to test after instead. If you’re doing it that way you have to be very critical as you comb through your existing solution for untested behavior. (That’s one occasion when a locally-run code coverage tool is useful).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I tend to be pretty good at TDD when the task at hand is "easy", when I know what I'm doing and don't need to experiment much, basically doing things I've done before.
When I'm working on stuff that may or may not work (trial and error) I get very frustrated with TDD and feel it's just slowing me down in my ability to prove a concept. Of course I will always go back and write some tests, but that's far from being TDD.
I wonder how people handle these situations? Really curious :)
I spike a lot (i.e., write code without tests) until I have an elegant design figured out. Strict TDD would then have you scrap that solution and re-write it with tests, but you may just want to test after instead. If you’re doing it that way you have to be very critical as you comb through your existing solution for untested behavior. (That’s one occasion when a locally-run code coverage tool is useful).