That supposes to have a clear idea of what you’re going to code. Otherwise, it’s a lot of time wasted to constantly rewrite both the code and tests as you better understand how you’re going to solve the task while trying. I guess it works for very narrowed tasks rather than opened problems.
The tests help you discover what needs to be written, too. Honestly, I can’t imagine starting to write code unless I have at least a rough concept of what to write.
Maybe I’m being judgemental (I don’t mean to be) but what I am trying to say is that, in my experience, writing tests as you code has usually lead to the best outcomes and often the fastest delivery times.
The only projects I’ve ever found interesting in my career was the stuff where nobody had any idea yet how the problem was going to be handled, and you’re right that starting with tests is not even possible in this scenario (prototyping is what’s really important). Whenever I’ve written yet another text/email/calling/video Skype clone for yet another cable company, it’s possible to start with tests because you already know everything that’s going into it.
constantly rewrite both the code and tests as you better understand how you’re going to solve the task while trying
The tests should be decoupled from the “how” though. It’s obviously not possible to completely decouple them, but if you’re “constantly” rewriting, something is going wrong.
That supposes to have a clear idea of what you’re going to code. Otherwise, it’s a lot of time wasted to constantly rewrite both the code and tests as you better understand how you’re going to solve the task while trying. I guess it works for very narrowed tasks rather than opened problems.
The tests help you discover what needs to be written, too. Honestly, I can’t imagine starting to write code unless I have at least a rough concept of what to write.
Maybe I’m being judgemental (I don’t mean to be) but what I am trying to say is that, in my experience, writing tests as you code has usually lead to the best outcomes and often the fastest delivery times.
The only projects I’ve ever found interesting in my career was the stuff where nobody had any idea yet how the problem was going to be handled, and you’re right that starting with tests is not even possible in this scenario (prototyping is what’s really important). Whenever I’ve written yet another text/email/calling/video Skype clone for yet another cable company, it’s possible to start with tests because you already know everything that’s going into it.
The tests should be decoupled from the “how” though. It’s obviously not possible to completely decouple them, but if you’re “constantly” rewriting, something is going wrong.
Brilliant talk on that topic (with slight audio problems): https://www.youtube.com/watch?v=EZ05e7EMOLM
Everything is made up of narrow tasks, you “just” need to break it down more :)