4 ms·
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
by 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 agoAre 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 agoIt'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 agoMy 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.
- js8 5y agoI don't think tests can ever replace specification, it's like trying to replace a mathematical proof with a computer experiment. Unless it's something like property-based tests, but even there.. My take on specification is that you encode it to be executable as your program, during development. Ideally, the program should encode the specs in the most straightforward way possible. To "specialize" the spec into tests first and then "generalize" it again from tests into a working program seems like unnecessary hassle, and frankly prone to information loss. It's interesting, because as I state in another comment, I have a big disagreement with a guy who loves TDD. I guess I am a theorist (I derive my feeling of correctness from simplicity of the code) and he is an empiricist (he derives his feeling of correctness from many small tests), and it somehow defines our approach.
- EVa5I7bHFq9mnYK 5y agoUltimate TDD is machine learning. You give the machine all the test cases, and it figures out the code. Except it doesn't work as well on out of test samples. Human oversight is still required.