3 ms·

> As a process it works. It's just 2x easier to write behavioral tests first and thrash out a good design later under its harness. I think this “2x easier” onl

by jt2190 3y ago

> As a process it works. It's just 2x easier to write behavioral tests first and thrash out a good design later under its harness. I think this “2x easier” only applies to developers who deeply understand how to design software. A very poorly designed implementation can still pass the high level tests, while also being hard to reason about (typically poor data structures) and debug, having excessive requirements for test setup and tear down due to lots of assumed state, and be hard to change, and might have no modularity at all, meaning that the tests cover tens of thousands of lines (but only the happy path, really). Code like this can still be valuable of course, since it satisfies the requirements and produces business value, however I’d say that it runs a high risk of being marked for a complete rewrite, likely by someone who also doesn’t really know how to design software. (Organizations that don’t know what well designed software looks like tend not to hire people who are good at it.)

deleted 3y ago
[deleted]
MoreQARespect 3y ago
"Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. I've seen plenty of horrible unit test driven developed code with a mess of unnecessary mocks. So no, this isnt about skill. "Test driven design" doesnt provide effective safety rails to prevent bad design from happening. It just causes more pain to those who use it as such. Experience is what is supposed to tell you how to react to that pain. In the hands of junior developers test driven design is more like test driven self flagellation in that respect: an exercise in unnecessary shame and humiliation. Moreover since it prevents those tests with a clusterfuck of mocks from operating as a reliable safety harness (because they fail when implementation code changes, not in the presence of bugs), it actively inhibits iterative exploration towards good design. These tests have the effect of locking in bad design because keeping tightly coupled low level tests green and refactoring is twice as much work as just refactoring without this type of test.
- User23 3y ago
  > I've seen plenty of horrible unit test driven developed code with a mess of unnecessary mocks. Mocks are an anti-pattern. They are a tool that either by design or unfortunate happenstance allows and encourages poor separation of concerns, thereby eliminating the single largest benefit of TDD: clean designs.
- jt2190 3y ago
  You asserted: > … TDD is a "design practice" but I find it to be completely wrongheaded. > The principle that tests that couple to low level code give you feedback about tightly coupled code is true but it does that because low level/unit tests couple too tightly to your code - I.e. because they too are bad code! But now you’re asserting: > "Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. Which feels like it contradicts your earlier assertion that TDD produces low-level unit tests. In other words, for there to be a “unit test” there must be a boundary around the “unit”, and if the code created by following TDD doesn’t even have module-sized units, then is that really TDD anymore? Edit: Or are you asserting that TDD doesn’t provide any direction at all about what kind of testing to do? If so, then what does it direct us to do?
  - MoreQARespect 3y ago
    >"Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. >Which feels like it contradicts your earlier assertion that TDD produces low-level unit tests. No, it doesnt contradict that at all. Test driven design, whether done optimally or suboptimally, produces low level unit tests. Whether the "feedback" from those tests is taken into account determines whether you get bad design or not. Either way I do not consider it a good practice. The person I was replying to was suggesting that it was a practice that was more suited to be people with a lack of experience. I dont think that is true. >Or are you asserting that TDD doesn’t provide any direction at all about what kind of testing to do? I'm saying that test driven design provides weak direction about design and it is not uncommon for test driven design to still produce bad designs because that weak direction is not followed by people with less experience. Thus I dont think it's a practice whose effectiveness is moderated by experience level. It's just a bad idea either way.

by jt2190 3y ago

deleted 3y ago

[deleted]

MoreQARespect 3y ago

"Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. I've seen plenty of horrible unit test driven developed code with a mess of unnecessary mocks. So no, this isnt about skill. "Test driven design" doesnt provide effective safety rails to prevent bad design from happening. It just causes more pain to those who use it as such. Experience is what is supposed to tell you how to react to that pain. In the hands of junior developers test driven design is more like test driven self flagellation in that respect: an exercise in unnecessary shame and humiliation. Moreover since it prevents those tests with a clusterfuck of mocks from operating as a reliable safety harness (because they fail when implementation code changes, not in the presence of bugs), it actively inhibits iterative exploration towards good design. These tests have the effect of locking in bad design because keeping tightly coupled low level tests green and refactoring is twice as much work as just refactoring without this type of test.

User23 3y ago
> I've seen plenty of horrible unit test driven developed code with a mess of unnecessary mocks. Mocks are an anti-pattern. They are a tool that either by design or unfortunate happenstance allows and encourages poor separation of concerns, thereby eliminating the single largest benefit of TDD: clean designs.
jt2190 3y ago
You asserted: > … TDD is a "design practice" but I find it to be completely wrongheaded. > The principle that tests that couple to low level code give you feedback about tightly coupled code is true but it does that because low level/unit tests couple too tightly to your code - I.e. because they too are bad code! But now you’re asserting: > "Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. Which feels like it contradicts your earlier assertion that TDD produces low-level unit tests. In other words, for there to be a “unit test” there must be a boundary around the “unit”, and if the code created by following TDD doesn’t even have module-sized units, then is that really TDD anymore? Edit: Or are you asserting that TDD doesn’t provide any direction at all about what kind of testing to do? If so, then what does it direct us to do?
- MoreQARespect 3y ago
  >"Test driven design" in the wrong hands will also lead to a poorly designed non modular implementation in less skilled hands. >Which feels like it contradicts your earlier assertion that TDD produces low-level unit tests. No, it doesnt contradict that at all. Test driven design, whether done optimally or suboptimally, produces low level unit tests. Whether the "feedback" from those tests is taken into account determines whether you get bad design or not. Either way I do not consider it a good practice. The person I was replying to was suggesting that it was a practice that was more suited to be people with a lack of experience. I dont think that is true. >Or are you asserting that TDD doesn’t provide any direction at all about what kind of testing to do? I'm saying that test driven design provides weak direction about design and it is not uncommon for test driven design to still produce bad designs because that weak direction is not followed by people with less experience. Thus I dont think it's a practice whose effectiveness is moderated by experience level. It's just a bad idea either way.