The activity of writing test-first is a cash flow balancing activity that you perform to trade future risk for current time and focus. I believe this is the primary trade-off that non-practitioners object to
```
To me, there is no trading off going on. When I write code, I will test the code. If I test it manually, then I will have to repeat the testing process every time I make changes. If I write code to test the code once, then the code will test the code every time. With TDD, I write the tests upfront. To me the actual benefit with TDD is not that it requires me to write tests. Writing tests is completely for the sake of writing code. TDD is about having clarity while writing code. It gives me the avenue to take moment & think about what I am going to do next, to define the parameters, to define the possible outputs, the implementation details. That is what TDD is fundamentally doing. If you are not following TDD, you will write the same tests for a given function, in which you will test all the control paths/inputs/outputs of the function. But, with TDD, instead of figuring out what needs to be done while writing the code, you think about the implementation upfront. Last bit: TDD helps me solve the problem before I began to code it.
I think that TDD is very underestimated. Is no silver bullet, as everything, but 90% of time is the best choice. And the main reason is the most underestimated skill you develop with TDD: baby steps. Become used to commit small pieces of advancement each minute or so totally changed my mindset. Benefits in productivity, but it becomes a new mindset - and it enables CI and TBD with more ease. So yes, TDD makes you more profitable for the company, in the end 🙂
And for those thinking “I can do baby steps without TDD” - good luck doing that without the TDD cycle supporting.
And it requires a whole lot of seemingly unrelated, specialised knowledge to varying levels of depth and understand.
In a way, being a software engineer is similar to being a sushi master. It’s not an exact science, rather a learned and honed craft, changing with the weather.
The value of TDD seems to me to be in continuously asking: "what will success (in this context: working software) look like?" and then working towards that.
My objection to TDD is mostly because I don't see TDD advocates often making that jump and in turn considering that "red-green-refactor" isn't always going to be the most effective way of asking that question (for example, I suspect type-driven-design will very often be more effective in the situations where it can be applied)
I believe this mindset is the problem:
```
The activity of writing test-first is a cash flow balancing activity that you perform to trade future risk for current time and focus. I believe this is the primary trade-off that non-practitioners object to
```
To me, there is no trading off going on. When I write code, I will test the code. If I test it manually, then I will have to repeat the testing process every time I make changes. If I write code to test the code once, then the code will test the code every time. With TDD, I write the tests upfront. To me the actual benefit with TDD is not that it requires me to write tests. Writing tests is completely for the sake of writing code. TDD is about having clarity while writing code. It gives me the avenue to take moment & think about what I am going to do next, to define the parameters, to define the possible outputs, the implementation details. That is what TDD is fundamentally doing. If you are not following TDD, you will write the same tests for a given function, in which you will test all the control paths/inputs/outputs of the function. But, with TDD, instead of figuring out what needs to be done while writing the code, you think about the implementation upfront. Last bit: TDD helps me solve the problem before I began to code it.
I think that TDD is very underestimated. Is no silver bullet, as everything, but 90% of time is the best choice. And the main reason is the most underestimated skill you develop with TDD: baby steps. Become used to commit small pieces of advancement each minute or so totally changed my mindset. Benefits in productivity, but it becomes a new mindset - and it enables CI and TBD with more ease. So yes, TDD makes you more profitable for the company, in the end 🙂
And for those thinking “I can do baby steps without TDD” - good luck doing that without the TDD cycle supporting.
Mastery of a single, small step can take decades.
And it requires a whole lot of seemingly unrelated, specialised knowledge to varying levels of depth and understand.
In a way, being a software engineer is similar to being a sushi master. It’s not an exact science, rather a learned and honed craft, changing with the weather.
The value of TDD seems to me to be in continuously asking: "what will success (in this context: working software) look like?" and then working towards that.
My objection to TDD is mostly because I don't see TDD advocates often making that jump and in turn considering that "red-green-refactor" isn't always going to be the most effective way of asking that question (for example, I suspect type-driven-design will very often be more effective in the situations where it can be applied)
Absolutely, red-green-refactor is an oversimplification that gets beginners hooked, similar to SOLID and DRY.
Thanks for commenting @levi