4 ms·

> I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs I am skeptical of TDD, so I have a genuine questi

by js8 5y ago

> I wouldn't go as far as the author saying TTD is useless as it's genuinely useful against most obvious bugs I am skeptical of TDD, so I have a genuine question. Let's say TDD is able to find the "most obvious" bugs, like a typo. My question is, why are these bugs worth creating a test for them, compared to either manual testing (running the program and looking at the output) or running a portion of the integrated test suite on the code to find them? If the bug is simple and crippling, then the program is likely to fail anyway. To me there is a tradeoff. With TDD, you write some unit test code, and it finds a trivial bug. But is every trivial bug found worth maintaining the unit test code going forward? I mean it's not like this bug is gonna appear again all of sudden in your code, unless you change it, but then in all likelihood you need to change your unit test as well. I guess I don't really see TDD as a good tool, because all the situations that you can run into are already covered by other, more specialized tools. If you want to catch edge cases, asserts are IMHO superior tool to tests. If you want to verify your program quickly, running it manually and looking at the output is superior. If you want to verify your program properly, running a comprehensive (and integrated) test suite is superior (the best if you can make it property-based). There are situations where unit tests are genuinely useful, like writing a library. But in those cases, unit tests seem to always either compare with some other implementation (for example, if I am testing a sin(x) function, my other implementation is the calculator), or at least compare with well-defined specification that comes outside the code. But I feel like majority of tests written for TDD are not really testing the code against anything (simply because another implementation or specification is not available), they just test the intent of the code itself as is written, which might be useful if you wanted to write "bar" but wrote "baz" by accident, but other than this type of bugs, what is their long-term contribution, that could justify the maintenance cost?

loopz 5y ago
The output of TDD is not the tests themselves, but the process of designing beforehand what is expected behaviour using up-front tests. The tests then acts as a guide to later development of code. Both should be adjusted during the discovery journey. The tests should then reflect the value that the code provides, and must be usable as-is in later refactors to have much worth themselves. "Acceptance criterias" should be self-evident from the ongoing development processes, and is not a final signoff. TDD tests would ideally be used for hunting business value, and focus on overall desired product behaviour and qualities.
- js8 5y ago
  Are you saying you want to replace the specification with tests? That's really dubious to me. I don't think it really helps software development, if instead of "here's the description of what we need to do" the SW developer gets "here's a few examples of what we need to do" (albeit if the examples can be automatically verified). If that's NOT your intent, what's the role of specification in the TDD, and how it's interacting with the implementation and the tests?
  - loopz 5y ago
    It's just the idea behind Test Driven Development, that tests drive development. It won't be very effective as a handover, though could be used as acceptance criterias if that is needed. The adherents really want tests to be the specification, as a way to be measurable / testable. Specs may be converted to tests. But most of it is theory. It all depends, as usual, on the dev(s) and circumstances.
    - fatnoah 5y ago
      My one and only truly TDD project went brilliantly, but there were specific circumstances. In this project, I created the back-end and API while an outsourced team built the UI. What made it work well was that I wrote the tests AND the spec at the same time, and kept both up to date. Completed tests equalled progress on the back-end, made it easy to identify any regressions in my own code, and clear differentiated between logic and general HTTP plumbing errors.
  - vikingerik 5y ago
    > Are you saying you want to replace the specification with tests? That's really dubious to me. That's pretty much it. The value is that tests can be automatically executed and verified. A specification document can't. Writing a spec is still a step in the process - a bootstrapping step. The spec is a "write one to throw away" placeholder until you get far enough that the spec can be replaced with executable tests.
    - 5y ago
groby_b 5y ago
TDD is double-entry bookkeeping. Done well, you've spec'd the behavior twice, once as constraints, and once as logic. It's of limited utility in the moment, but it's invaluable going forward, as you make changes. (The in-the-moment use is about surfacing API design forces, and I'm not sure TDD is the best way to achieve good design)
- js8 5y ago
  I like the double-entry bookkeeping analogy, but isn't it true for all tests? In fact, as the article explains, in the old days it was a specialized QA department (different from development) which wrote tests often just based on specs, and the barrier (also called black-box testing) was there precisely to have independent verification. It seems to me that this argument favors the old methods and not TDD in particular.
  - groby_b 5y ago
    The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in your model of the world. The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing) I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact) You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)
glopes 5y ago
In my opinion TDD really only exploded in modern SW industry due to the shift to dynamic languages like Javascript and Python where you can’t even rely on the compiler to help you with types and typos. Unit tests still help of course with static typed languages but you really don’t need to be afraid that refactoring can kill your entire code base as you have formal proof that types and names agree as part of your IDE and build process by default.
EVa5I7bHFq9mnYK 5y ago
Testing serves the same function as type system in C++ - it imposes restrictions on the code and automates checking for those restrictions. It became absolutely necessary with the advent of type-less languages such as JavaScript or PHP.

by js8 5y ago

loopz 5y ago

The output of TDD is not the tests themselves, but the process of designing beforehand what is expected behaviour using up-front tests. The tests then acts as a guide to later development of code. Both should be adjusted during the discovery journey. The tests should then reflect the value that the code provides, and must be usable as-is in later refactors to have much worth themselves. "Acceptance criterias" should be self-evident from the ongoing development processes, and is not a final signoff. TDD tests would ideally be used for hunting business value, and focus on overall desired product behaviour and qualities.

js8 5y ago
Are you saying you want to replace the specification with tests? That's really dubious to me. I don't think it really helps software development, if instead of "here's the description of what we need to do" the SW developer gets "here's a few examples of what we need to do" (albeit if the examples can be automatically verified). If that's NOT your intent, what's the role of specification in the TDD, and how it's interacting with the implementation and the tests?
- loopz 5y ago
  It's just the idea behind Test Driven Development, that tests drive development. It won't be very effective as a handover, though could be used as acceptance criterias if that is needed. The adherents really want tests to be the specification, as a way to be measurable / testable. Specs may be converted to tests. But most of it is theory. It all depends, as usual, on the dev(s) and circumstances.
  - fatnoah 5y ago
    My one and only truly TDD project went brilliantly, but there were specific circumstances. In this project, I created the back-end and API while an outsourced team built the UI. What made it work well was that I wrote the tests AND the spec at the same time, and kept both up to date. Completed tests equalled progress on the back-end, made it easy to identify any regressions in my own code, and clear differentiated between logic and general HTTP plumbing errors.
- vikingerik 5y ago
  > Are you saying you want to replace the specification with tests? That's really dubious to me. That's pretty much it. The value is that tests can be automatically executed and verified. A specification document can't. Writing a spec is still a step in the process - a bootstrapping step. The spec is a "write one to throw away" placeholder until you get far enough that the spec can be replaced with executable tests.
  - 5y ago

groby_b 5y ago

TDD is double-entry bookkeeping. Done well, you've spec'd the behavior twice, once as constraints, and once as logic. It's of limited utility in the moment, but it's invaluable going forward, as you make changes. (The in-the-moment use is about surfacing API design forces, and I'm not sure TDD is the best way to achieve good design)

js8 5y ago
I like the double-entry bookkeeping analogy, but isn't it true for all tests? In fact, as the article explains, in the old days it was a specialized QA department (different from development) which wrote tests often just based on specs, and the barrier (also called black-box testing) was there precisely to have independent verification. It seems to me that this argument favors the old methods and not TDD in particular.
- groby_b 5y ago
  The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in your model of the world. The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing) I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact) You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)

glopes 5y ago

In my opinion TDD really only exploded in modern SW industry due to the shift to dynamic languages like Javascript and Python where you can’t even rely on the compiler to help you with types and typos. Unit tests still help of course with static typed languages but you really don’t need to be afraid that refactoring can kill your entire code base as you have formal proof that types and names agree as part of your IDE and build process by default.

EVa5I7bHFq9mnYK 5y ago

Testing serves the same function as type system in C++ - it imposes restrictions on the code and automates checking for those restrictions. It became absolutely necessary with the advent of type-less languages such as JavaScript or PHP.