Thank you for the article. I think there is even some literature about this, telling us that it's important to write tests before or after the corresponding code but that it doesn't matter which one around. Sadly I don't know the source since it's prime hearsay from a podcast.
"The tasks of programming are many, and some are very suitable for tastings, while others, are not."
Did you really mean tasting?
Maybe the junior programmers break room coffee? :-)
"I've met people for whom it works, a few exceptions, very good programmers, methodical, experimented."
Experimented? Were they experimented on or are they just experienced?
> TDD comes with another hidden assumption: it's that you know the solution to your problem.
I think this is one of the biggest misunderstandings about TDD. TDD does not imply that you need to write a test first for tasks that you don't yet understand. To address this issue, people came up with 'spiking' - it's when you, trying to figure out a problem, write a simple prototype without tests in order to understand the issue. Then, once you have all the answers, you return to TDD - rewriting your "dirty" solution.
Also I want to quote something from the internet:
```
In software development, sometimes we aren’t sure how to solve a problem. It may happen when you are using a new API, framework, or just because you never had a similar problem before. Using TDD in this scenario is hard. In order to write the test first, you need to be able to define the expectations, if you don’t know that, TDD is gonna be really challenging. In Agile Development there’s a technique for this situation called Spike. This term comes from Extreme Programming, where “A spike solution is a very simple program to explore potential solutions”. To implement a spike solution, you normally create a small program very quickly testing the problem in question. When you have the answers that you need, you go back and build it again, but this time using TDD.
Great essay! Says everything I have thought about TDD, much more coherently, and says a lot more, besides. Thanks for the effort, and the voice of experience.
Some good points, but I admit I don't agree with everything you said
I think this post may answer some of your points
https://blog.thecodewhisperer.com/permalink/tdd-for-those-who-dont-know-how-to-design-software
I'm relieved I'm not the only one struggling with TDD :)
Loved the article, there are a bunch of hot takes! ha
Thank you for sharing your experience.
Thank you for the article. I think there is even some literature about this, telling us that it's important to write tests before or after the corresponding code but that it doesn't matter which one around. Sadly I don't know the source since it's prime hearsay from a podcast.
"The tasks of programming are many, and some are very suitable for tastings, while others, are not."
Did you really mean tasting?
Maybe the junior programmers break room coffee? :-)
"I've met people for whom it works, a few exceptions, very good programmers, methodical, experimented."
Experimented? Were they experimented on or are they just experienced?
Best!
> TDD comes with another hidden assumption: it's that you know the solution to your problem.
I think this is one of the biggest misunderstandings about TDD. TDD does not imply that you need to write a test first for tasks that you don't yet understand. To address this issue, people came up with 'spiking' - it's when you, trying to figure out a problem, write a simple prototype without tests in order to understand the issue. Then, once you have all the answers, you return to TDD - rewriting your "dirty" solution.
Also I want to quote something from the internet:
```
In software development, sometimes we aren’t sure how to solve a problem. It may happen when you are using a new API, framework, or just because you never had a similar problem before. Using TDD in this scenario is hard. In order to write the test first, you need to be able to define the expectations, if you don’t know that, TDD is gonna be really challenging. In Agile Development there’s a technique for this situation called Spike. This term comes from Extreme Programming, where “A spike solution is a very simple program to explore potential solutions”. To implement a spike solution, you normally create a small program very quickly testing the problem in question. When you have the answers that you need, you go back and build it again, but this time using TDD.
```
Great essay! Says everything I have thought about TDD, much more coherently, and says a lot more, besides. Thanks for the effort, and the voice of experience.