This is why you write the test before the code. You write the test to make sure something fails, then you write the code to make it pass. Then you repeat this until all your behaviors are captured in code. It’s called TDD
But, full marks for writing tests in the first place
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 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.
TDD doesn’t imply that you write all the tests first. It just mean you have to write a test before you write a line of production code.
The idea is to ask yourself “what is the first step I need, where am I going to begin?”. You then write a test that validate this first step and fail. Then you write the code to make it pass. Once your done with that, you ask yourself: "what’s the next step? ". You, then, repeat the process for that step.
This is a process you are going to do anyway. Might as well take the time to write some test along with it.
That leads to focusing on the nitty gritty details first, building a library of thing you think you might need and you forget to think about the whole solution.
If you come up with another solution half way through, you will probably throw away half of the code you already built.
I see TDD as going depth first whereas I prefer to go breadth first. Try out a solution and skip the details (by mocking or assuming things). Once you have settled on the right solution you can fill in the details.
This is why you write the test before the code. You write the test to make sure something fails, then you write the code to make it pass. Then you repeat this until all your behaviors are captured in code. It’s called TDD
But, full marks for writing tests in the first place
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 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
100%. TDD is just not practicably applicable to a lot of scenarios and I wish evangelists were clearer on that detail.
This is the reason I dislike TDD.
TDD doesn’t imply that you write all the tests first. It just mean you have to write a test before you write a line of production code.
The idea is to ask yourself “what is the first step I need, where am I going to begin?”. You then write a test that validate this first step and fail. Then you write the code to make it pass. Once your done with that, you ask yourself: "what’s the next step? ". You, then, repeat the process for that step.
This is a process you are going to do anyway. Might as well take the time to write some test along with it.
That leads to focusing on the nitty gritty details first, building a library of thing you think you might need and you forget to think about the whole solution.
If you come up with another solution half way through, you will probably throw away half of the code you already built.
I see TDD as going depth first whereas I prefer to go breadth first. Try out a solution and skip the details (by mocking or assuming things). Once you have settled on the right solution you can fill in the details.