There are a number of things that I find I don't like about TDD.
TDD is not about tests or testing, it is about design. But I don't like the design it promotes. Actually I have mixed feelings. The main complaint is that it can cause what would be a straight forward implementation and convolute it with abstractions and boilerplate.
What is nice is that the code can become easily exercised without full system execution. However this is good when the design chosen is pure functions, but all too frequently I see layers of mock and dependency injection frameworks used to manage dependency creation rather than dependency reduction.
D is such a blast to create compile time testable code.
You can do whatever design you want or your knowledge allows you to do. TDD will not stop you. It shows that you have problems by being fragile, not reliable, hard to maintain and understand.
If you need alot of unrelated boilerplate to exercise one behavior this is an indicator that your design can be problematic. But nothing will stop you to keep move forward with it.
I wasn't referring to boilerplate within the test. In order to write specific test scenarios it can require a set of interfaces or you need to use pure functions with PODs. You have to build the code such that it can be tested (in isolation) with code.
There is another name for isolation: Low Coupling and High Cohesion. These are concepts of good design for ages.
But, again, TDD don't force you to follow them. You can do a very good spaghetti code using TDD and never look back, even feeling the pain related to it.
It's not TDD that promotes such design. It is the programming practice itself. The collective knowledge of our field that had discovered some really important and useful practices, patterns and principles to guide us in our journey.
But, again, if you really, really, reaally, want then nothing will stop you of not follow any of these practices, patterns and principles when doing TDD.
At the end of the day, you are the guy making decisions, creating architectures and solving problems (or amplifying them =p).
But TDD specifies that you are supposed to test one thing. It is not as the name suggest, put down any test in any way and then build. Following TDD is much more opinionated then you make it out to be.
Yeah, you exercise one piece of the behavior, then move to the next one. I was not in that level of detail while stating my claims. I just assumed it was not needed. My bad.
Even exercising one piece at a time you can bloat you code and make it very hard to make specs for it, to make changes on it, etc. So in a nutshell and as an overview, I'm saying that you will do the design that you know and that can be bad or good. TDD doesn't care. It will not stop you from doing it. It is different from a MVC framework that states you need to make the controller name same as the view folder or something like that, this is opinionated. TDD is not like this. So, there is not a promotion to a certain kind of design.
This kind of design is promoted by our field itself. Not by TDD. This is my argument.
Hope I've made myself clear now as english is not my native language. Sorry for any mistakes and misunderstandings. Cheers.
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.
There are a number of things that I find I don't like about TDD.
TDD is not about tests or testing, it is about design. But I don't like the design it promotes. Actually I have mixed feelings. The main complaint is that it can cause what would be a straight forward implementation and convolute it with abstractions and boilerplate.
What is nice is that the code can become easily exercised without full system execution. However this is good when the design chosen is pure functions, but all too frequently I see layers of mock and dependency injection frameworks used to manage dependency creation rather than dependency reduction.
D is such a blast to create compile time testable code.
TDD doesn't promote any design. You do. TDD, at best, can show you your design is flawed.
That is never anything I've heard.
"show you your design is flawed."
Isn't that what promotion would be in this context? How can it show a bad design if it does not expect some elements of design?
You can do whatever design you want or your knowledge allows you to do. TDD will not stop you. It shows that you have problems by being fragile, not reliable, hard to maintain and understand.
If you need alot of unrelated boilerplate to exercise one behavior this is an indicator that your design can be problematic. But nothing will stop you to keep move forward with it.
So no, the design is entirely up to you.
I wasn't referring to boilerplate within the test. In order to write specific test scenarios it can require a set of interfaces or you need to use pure functions with PODs. You have to build the code such that it can be tested (in isolation) with code.
There is another name for isolation: Low Coupling and High Cohesion. These are concepts of good design for ages.
But, again, TDD don't force you to follow them. You can do a very good spaghetti code using TDD and never look back, even feeling the pain related to it.
It's not TDD that promotes such design. It is the programming practice itself. The collective knowledge of our field that had discovered some really important and useful practices, patterns and principles to guide us in our journey.
But, again, if you really, really, reaally, want then nothing will stop you of not follow any of these practices, patterns and principles when doing TDD.
At the end of the day, you are the guy making decisions, creating architectures and solving problems (or amplifying them =p).
But TDD specifies that you are supposed to test one thing. It is not as the name suggest, put down any test in any way and then build. Following TDD is much more opinionated then you make it out to be.
Yeah, you exercise one piece of the behavior, then move to the next one. I was not in that level of detail while stating my claims. I just assumed it was not needed. My bad.
Even exercising one piece at a time you can bloat you code and make it very hard to make specs for it, to make changes on it, etc. So in a nutshell and as an overview, I'm saying that you will do the design that you know and that can be bad or good. TDD doesn't care. It will not stop you from doing it. It is different from a MVC framework that states you need to make the controller name same as the view folder or something like that, this is opinionated. TDD is not like this. So, there is not a promotion to a certain kind of design.
This kind of design is promoted by our field itself. Not by TDD. This is my argument.
Hope I've made myself clear now as english is not my native language. Sorry for any mistakes and misunderstandings. Cheers.