5 ms·

I think the simple claim that TDD improves design isn't strictly true, and turns some people away from automated testing. Never really heard this claim before

I think the simple claim that TDD improves design isn't strictly true, and turns some people away from automated testing. Never really heard this claim before ?

beardedwizard 3y ago
Came to say this, never heard this before. I have heard the claim that it improves quality, but even that is debatable. Im sure the most basic claim that can be proven is it often increases test coverage.
- js8 3y ago
  Improvement in quality is improvement in design, since having less bugs is one of the desired properties of good design.
  - bayindirh 3y ago
    A bad design may work equally well when compared to a good design, given it's patched enough.
  - wizofaus 3y ago
    Unless the bug fixes are so fragile and/or convoluted they make any change in business requirements almost impossible to implement.
  - beardedwizard 3y ago
    Totally disagree. A bad design can pass all tests and appear high quality, then crumble under high load. Even quality is subjective. Most people would assume it means being good at every aspect, but passing tests doesn't not guarantee that.
gumballindie 3y ago
It's a common fallacy among some software developers that since TDD forces you to write small units of code (since you have to write small unit tests then naturally the units you test will also be small) then your code will be easy to maintain. It also forces dependency injection in OOP and a couple other design patterns. I've seen code written as if by one's feet without unit tests that worked better than code with 90% test coverage. In a few cases tdd was the go to practice for sloppy devs. Somehow they thought that writing tests will account for lack of skill. But guess what? Tests were sloppy too.
- wizofaus 3y ago
  I don't think anybody could claim TDD will make a sloppy dev write good code. Though there's half an argument for getting more experienced/skilled devs to write the tests and the more junior or less capable ones to fill in the actual working implementation (but I'll be honest, I've never seen this work in practice over a prolonged period).
  - gumballindie 3y ago
    > (but I'll be honest, I've never seen this work in practice over a prolonged period) Me neither. I think that can only work when the same thing has been done countless times before. But at that point you can just use someone else's work, either via a library or an off the shelf product, instead of reinventing the wheel. And then you are left with working only on something that's new. Which invites the question - how can you test that which you don't know you need? In the context of unit testing that is.
sbergot 3y ago
It is a common claim made by TDD proponent. The reasoning is that it gives you a better perspective of the external facing apis you are developing because you are forced to use them when writing the tests.
deleted 3y ago
[deleted]
rewmie 3y ago
> Never really heard this claim before ? Neither did I. I guess it really depends on what the code would be like without having the constraints to make it testable. A big ball of mud component hardly qualifies as good design, and TDD definitely dissuades people from that mistake.
- TylerE 3y ago
  A big ball of mocks and ten thousand layers of abstraction is so much better!
  - rewmie 3y ago
    If the unit of code you want to test needs a big ball of mocks and ten thousand layers of abstraction to be testable, your code is already horrible and TDD was not the cause.
ryandv 3y ago
If tests are written first, (_and_ the dev has a good eye for design, which is not always given) then it is likelier that you will write a more ergonomic interface (e.g. methods having smaller number of parameters/dependencies, "intention revealing names", [0] etc..). In a unit-testing paradigm, this also means that you will need to inject the unit's dependencies so that it can be driven into specific states by each test in the suite, encouraging dependency inversion and the open/closed principle (as given by Uncle Bob [1]; note that with dependency inversion it becomes possible to vary the behaviour of the unit in test vs. production environments simply by specifying different dependencies without modifying the unit's code itself). If the dependencies are too cumbersome or even impossible to set up, then the test reveals something about the design (e.g. high coupling). Of course, it's also possible to just grin and bear the pain of tests being too difficult to write, without actually resolving the design problems revealed by the test... [0] https://wiki.c2.com/?IntentionRevealingNames https://wiki.c2.com/?IntentionRevealingNames [1] https://web.archive.org/web/20060822033314/http://www.objectmentor.com/resources/articles/ocp.pdf https://web.archive.org/web/20060822033314/http://www.object...
charlysisto 3y ago
I heard this a few times in the ruby community by some well known figures like Sandy Metz. Simple example : time related tests can be cumbersome to setup, but if you inject time in the method, test becomes easy, incidentally improving your design by not relying on globale objects... But I am sceptical this can work without knowing and practicing good design principles (SOLID) independently from tests ! However I believe tests are super important for refactoring, wether the design is good or not. My 2 cents : if the design is bad, (spaghetti and all) tests should be done more at the functional level, when your confident design is getting good then rely more on unit test

I think the simple claim that TDD improves design isn't strictly true, and turns some people away from automated testing. Never really heard this claim before ?

beardedwizard 3y ago

Came to say this, never heard this before. I have heard the claim that it improves quality, but even that is debatable. Im sure the most basic claim that can be proven is it often increases test coverage.

js8 3y ago
Improvement in quality is improvement in design, since having less bugs is one of the desired properties of good design.
- bayindirh 3y ago
  A bad design may work equally well when compared to a good design, given it's patched enough.
- wizofaus 3y ago
  Unless the bug fixes are so fragile and/or convoluted they make any change in business requirements almost impossible to implement.
- beardedwizard 3y ago
  Totally disagree. A bad design can pass all tests and appear high quality, then crumble under high load. Even quality is subjective. Most people would assume it means being good at every aspect, but passing tests doesn't not guarantee that.

gumballindie 3y ago

It's a common fallacy among some software developers that since TDD forces you to write small units of code (since you have to write small unit tests then naturally the units you test will also be small) then your code will be easy to maintain. It also forces dependency injection in OOP and a couple other design patterns. I've seen code written as if by one's feet without unit tests that worked better than code with 90% test coverage. In a few cases tdd was the go to practice for sloppy devs. Somehow they thought that writing tests will account for lack of skill. But guess what? Tests were sloppy too.

wizofaus 3y ago
I don't think anybody could claim TDD will make a sloppy dev write good code. Though there's half an argument for getting more experienced/skilled devs to write the tests and the more junior or less capable ones to fill in the actual working implementation (but I'll be honest, I've never seen this work in practice over a prolonged period).
- gumballindie 3y ago
  > (but I'll be honest, I've never seen this work in practice over a prolonged period) Me neither. I think that can only work when the same thing has been done countless times before. But at that point you can just use someone else's work, either via a library or an off the shelf product, instead of reinventing the wheel. And then you are left with working only on something that's new. Which invites the question - how can you test that which you don't know you need? In the context of unit testing that is.

sbergot 3y ago

It is a common claim made by TDD proponent. The reasoning is that it gives you a better perspective of the external facing apis you are developing because you are forced to use them when writing the tests.

deleted 3y ago

[deleted]

rewmie 3y ago

> Never really heard this claim before ? Neither did I. I guess it really depends on what the code would be like without having the constraints to make it testable. A big ball of mud component hardly qualifies as good design, and TDD definitely dissuades people from that mistake.

TylerE 3y ago
A big ball of mocks and ten thousand layers of abstraction is so much better!
- rewmie 3y ago
  If the unit of code you want to test needs a big ball of mocks and ten thousand layers of abstraction to be testable, your code is already horrible and TDD was not the cause.

ryandv 3y ago

If tests are written first, (_and_ the dev has a good eye for design, which is not always given) then it is likelier that you will write a more ergonomic interface (e.g. methods having smaller number of parameters/dependencies, "intention revealing names", [0] etc..). In a unit-testing paradigm, this also means that you will need to inject the unit's dependencies so that it can be driven into specific states by each test in the suite, encouraging dependency inversion and the open/closed principle (as given by Uncle Bob [1]; note that with dependency inversion it becomes possible to vary the behaviour of the unit in test vs. production environments simply by specifying different dependencies without modifying the unit's code itself). If the dependencies are too cumbersome or even impossible to set up, then the test reveals something about the design (e.g. high coupling). Of course, it's also possible to just grin and bear the pain of tests being too difficult to write, without actually resolving the design problems revealed by the test... [0] https://wiki.c2.com/?IntentionRevealingNames https://wiki.c2.com/?IntentionRevealingNames [1] https://web.archive.org/web/20060822033314/http://www.objectmentor.com/resources/articles/ocp.pdf https://web.archive.org/web/20060822033314/http://www.object...

charlysisto 3y ago

I heard this a few times in the ruby community by some well known figures like Sandy Metz. Simple example : time related tests can be cumbersome to setup, but if you inject time in the method, test becomes easy, incidentally improving your design by not relying on globale objects... But I am sceptical this can work without knowing and practicing good design principles (SOLID) independently from tests ! However I believe tests are super important for refactoring, wether the design is good or not. My 2 cents : if the design is bad, (spaghetti and all) tests should be done more at the functional level, when your confident design is getting good then rely more on unit test