7 ms·

The big TDD misunderstanding is that most people consider TDD a testing practice. The article doesn’t talk about TDD, it gives the reader some tips on how to w

by emadb 3y ago

The big TDD misunderstanding is that most people consider TDD a testing practice. The article doesn’t talk about TDD, it gives the reader some tips on how to write tests. That’s not TDD.

shimst3r 3y ago
Instead of Test-Driven Design, it should’ve been called Design-By-Testing.
- paulluuk 3y ago
  Did you mean Test Driven Development, or is Test-Driven Design a whole other thing?
skrebbel 3y ago
Yeah it’s kind of unfortunate because they make a very good argument about defining a thing better, and in the title use a wrong definition of an adjacent term.
WolfOliver 3y ago
Maybe the term TDD in the title can be replaced with "unit testing". But unit testing is an major part of TDD.
MoreQARespect 3y ago
I'm fully aware of the idea that 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! Have you ever refactored working code into working code and had a slew of tests fail anyway? That's the child of test driven design. High level/integration TDD doesnt give "feedback" on your design it just tells you if your code matches the spec. This is actually more useful. It then lets you refactor bad code with a safety harness and give failures that actually mean failure and not "changed code". I keep wishing for the idea of test driven design to die. Writing tests which break on working code is inordinately uneconomic way to detect design issues as compared to developing an eye for it and fixing it under a test harness with no opinion on your design. So, yes this - high level test driven development - is TDD and moreover it's got a better cost/benefit trade off than test driven design.
- surgical_fire 3y ago
  I don't even like TDD much, but I think that this missed the point: > Have you ever refactored working code into working code and had a slew of tests fail anyway? Yes - and that is intended. The "refactor of working code into working code" often changes some assumptions that were made during implementation. Those tests are not there to give "feedback on your design", they are there to endure that the implementation does what you thought it should do when you wrote your code. Yes, that means that when you refactor your code, quite a few tests will have to be changed to match the new code. But the amount of times I had this happen and it highlighted issues on the refactor is definitely not negligible. The cost of not having these tests (which would translate into bugs) would certainly have surpassed the costs of keeping those tests around.
  - gavmor 3y ago
    "Have you ever reconsidered your path up the cliff face and had to reposition a slew of pitons? This means your pitons are too tightly coupled to the route!"
  - thom 3y ago
    If we’re talking “what you thought it should do” and not “how you thought it should do it” this is all fine. If requirements change tests should change. I think the objection is more to changing implementation details and having to rewrite twice as much code, when your functional tests (which test things that actually make you money) never changed.
    - chris_wot 3y ago
      If your functional tests fail because you made an “unrelated” code change, then you’ve done something wrong.
      - naasking 3y ago
        Maybe, but I think the point is that it's probably very easy to get into this situation, and not many people talk about it or point out how to avoid it.
danmaz74 3y ago
As I remember the discourse about TDD, originally it was described as a testing practice, and later people started proposing to change the last D from "development" to "design".
deneas 3y ago
I mean I think it's fair to assume that TEST-Driven-Development has something to do with testing. That being said, Kent Beck recently (https://tidyfirst.substack.com/p/tdd-outcomes https://tidyfirst.substack.com/p/tdd-outcomes) raised a point saying TDD doesn't have to be just an X technique, which I wholeheartedly agree with.
marcosdumay 3y ago
Well, it's exactly as much about testing as it focus on writing and running tests. What means, it's absolutely entirely about them. People can claim it's about requirements all they want. The entire thing runs around the tests, and there's absolutely no consideration to the requirements except on the part where you map them into tests. If you try to create a requirements framework, you'll notice that there is much more to them than testing if they are met.

by emadb 3y ago

The big TDD misunderstanding is that most people consider TDD a testing practice. The article doesn’t talk about TDD, it gives the reader some tips on how to write tests. That’s not TDD.

shimst3r 3y ago

Instead of Test-Driven Design, it should’ve been called Design-By-Testing.

paulluuk 3y ago
Did you mean Test Driven Development, or is Test-Driven Design a whole other thing?

skrebbel 3y ago

Yeah it’s kind of unfortunate because they make a very good argument about defining a thing better, and in the title use a wrong definition of an adjacent term.

WolfOliver 3y ago

Maybe the term TDD in the title can be replaced with "unit testing". But unit testing is an major part of TDD.

MoreQARespect 3y ago

I'm fully aware of the idea that 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! Have you ever refactored working code into working code and had a slew of tests fail anyway? That's the child of test driven design. High level/integration TDD doesnt give "feedback" on your design it just tells you if your code matches the spec. This is actually more useful. It then lets you refactor bad code with a safety harness and give failures that actually mean failure and not "changed code". I keep wishing for the idea of test driven design to die. Writing tests which break on working code is inordinately uneconomic way to detect design issues as compared to developing an eye for it and fixing it under a test harness with no opinion on your design. So, yes this - high level test driven development - is TDD and moreover it's got a better cost/benefit trade off than test driven design.

surgical_fire 3y ago
I don't even like TDD much, but I think that this missed the point: > Have you ever refactored working code into working code and had a slew of tests fail anyway? Yes - and that is intended. The "refactor of working code into working code" often changes some assumptions that were made during implementation. Those tests are not there to give "feedback on your design", they are there to endure that the implementation does what you thought it should do when you wrote your code. Yes, that means that when you refactor your code, quite a few tests will have to be changed to match the new code. But the amount of times I had this happen and it highlighted issues on the refactor is definitely not negligible. The cost of not having these tests (which would translate into bugs) would certainly have surpassed the costs of keeping those tests around.
- gavmor 3y ago
  "Have you ever reconsidered your path up the cliff face and had to reposition a slew of pitons? This means your pitons are too tightly coupled to the route!"
- thom 3y ago
  If we’re talking “what you thought it should do” and not “how you thought it should do it” this is all fine. If requirements change tests should change. I think the objection is more to changing implementation details and having to rewrite twice as much code, when your functional tests (which test things that actually make you money) never changed.
  - chris_wot 3y ago
    If your functional tests fail because you made an “unrelated” code change, then you’ve done something wrong.
    - naasking 3y ago
      Maybe, but I think the point is that it's probably very easy to get into this situation, and not many people talk about it or point out how to avoid it.

danmaz74 3y ago

As I remember the discourse about TDD, originally it was described as a testing practice, and later people started proposing to change the last D from "development" to "design".

deneas 3y ago

I mean I think it's fair to assume that TEST-Driven-Development has something to do with testing. That being said, Kent Beck recently (https://tidyfirst.substack.com/p/tdd-outcomes https://tidyfirst.substack.com/p/tdd-outcomes) raised a point saying TDD doesn't have to be just an X technique, which I wholeheartedly agree with.

marcosdumay 3y ago

Well, it's exactly as much about testing as it focus on writing and running tests. What means, it's absolutely entirely about them. People can claim it's about requirements all they want. The entire thing runs around the tests, and there's absolutely no consideration to the requirements except on the part where you map them into tests. If you try to create a requirements framework, you'll notice that there is much more to them than testing if they are met.