4 ms·

It is a trivial example, no question. It's part of a bigger tutorial example you can find here: https://www.letscodejavascript.com/v3/comments/tdd_intro/5 http

It is a trivial example, no question. It's part of a bigger tutorial example you can find here: https://www.letscodejavascript.com/v3/comments/tdd_intro/5 https://www.letscodejavascript.com/v3/comments/tdd_intro/5 There's a different, written example here (scroll down to "A TDD Example"): https://www.jamesshore.com/Agile-Book/test_driven_development.html https://www.jamesshore.com/Agile-Book/test_driven_developmen... Those examples are for beginners, and not totally representative of the real world. For real-world TDD, check out my "Let's Play TDD" or "Let's Code JavaScript" screencasts, which are listed in my profile. > Have I deeply misunderstood TDD? Maybe? A defining feature of TDD is that you iterate, so you wouldn't take 2-20 minutes to write a series of tests. Instead, you'd write one test, get that to work, modify it or write the next test, get that to work, etc. Part of the skill of doing TDD well is figuring out which tests to write first, so that this iterative cycle forms a smooth path from beginning to end, while still allowing you to discover new things about your requirements and design as you go. Another part of the skill is testing the behavior of your code, not its implementation, so that you don't overconstrain the implementation. Implementation changes that don't affect behavior shouldn't require test changes. This is hard and many people struggle with this. TDD is easy to learn but hard to master. I personally find it very worthwhile. The confidence it gives me in my code is very freeing, and I like not having to spend much time debugging. TDD isn't perfect, nothing is, but the problems the OP described don't match my experience.

zestyping 7y ago
The place where I'm getting stuck is the claim that all programming can be done in steps that small. That just doesn't seem realistic. For instance, how could one possibly write a complete test for the behaviour of a regular expression that matches a C comment in less than 2 minutes or even 5 minutes? The test has to be understandable to other readers, so I would easily spend a few minutes just documenting it carefully so that other readers could convince themselves that the test is complete.
- jdlshore 7y ago
  You build it up gradually. For example, let's say we're writing an isComment function (and please excuse any misunderstandings about C comment syntax): Test: it("starts and ends with slash-star", function() { assert.isTrue(isComment("/**/"), "empty comment"); assert.isFalse(isComment(""), "empty string"); assert.isFalse(isComment("foo"), "not a comment"); }); Code: isComment(text) { return text.matches(/\/\*\*\//); // excuse any errors; haven't actually tried this } That's the first TDD loop. Takes less than a minute. But it's obviously incomplete, so now we build it up, step by step. Add another test: it("can contain text", function() { assert.isTrue(isComment("/* foo */")); } Modify the code: isComment(text) { return text.matches(/\/\*.*?\*\//); } That also takes less than a minute. We continue in this way, step by step, handling more and more specific edge cases, until we think we've handled all the cases. For example, the next test might be it("can span multiple lines").
  - zestyping 7y ago
    Hmm. Okay, so my incorrect assumption was that the test has to be correct. In this process, it is okay for the test to be incomplete. I've been pondering why this feels so counterintuitive to me. I think it's because, in traditional testing, the test is treated as authoritative. Your test is supposed to be 100% correct, and then you make the code good enough to pass the test. The word "test" suggests a teacher grading an exam: the teacher must be 100% correct. So, I wonder if it is helpful when explaining this approach to explicitly set aside this assumption. The program and the test can both be incomplete. Would it be an overstatement to say it seems like the test and the program have more of a symmetric relationship, rather than an asymmetric one? Thanks for taking the time to explain this!
    - jdlshore 7y ago
      You're welcome! I'm not sure what you mean by symmetric vs. asymmetric relationships, but if you mean that they're developed in parallel, both as first-class citizens, with each informing the other, and each taking about the same amount of time and code, then yes. Or you could also call it a symbiotic relationship.

zestyping 7y ago

The place where I'm getting stuck is the claim that all programming can be done in steps that small. That just doesn't seem realistic. For instance, how could one possibly write a complete test for the behaviour of a regular expression that matches a C comment in less than 2 minutes or even 5 minutes? The test has to be understandable to other readers, so I would easily spend a few minutes just documenting it carefully so that other readers could convince themselves that the test is complete.

jdlshore 7y ago
You build it up gradually. For example, let's say we're writing an isComment function (and please excuse any misunderstandings about C comment syntax): Test: it("starts and ends with slash-star", function() { assert.isTrue(isComment("/**/"), "empty comment"); assert.isFalse(isComment(""), "empty string"); assert.isFalse(isComment("foo"), "not a comment"); }); Code: isComment(text) { return text.matches(/\/\*\*\//); // excuse any errors; haven't actually tried this } That's the first TDD loop. Takes less than a minute. But it's obviously incomplete, so now we build it up, step by step. Add another test: it("can contain text", function() { assert.isTrue(isComment("/* foo */")); } Modify the code: isComment(text) { return text.matches(/\/\*.*?\*\//); } That also takes less than a minute. We continue in this way, step by step, handling more and more specific edge cases, until we think we've handled all the cases. For example, the next test might be it("can span multiple lines").
- zestyping 7y ago
  Hmm. Okay, so my incorrect assumption was that the test has to be correct. In this process, it is okay for the test to be incomplete. I've been pondering why this feels so counterintuitive to me. I think it's because, in traditional testing, the test is treated as authoritative. Your test is supposed to be 100% correct, and then you make the code good enough to pass the test. The word "test" suggests a teacher grading an exam: the teacher must be 100% correct. So, I wonder if it is helpful when explaining this approach to explicitly set aside this assumption. The program and the test can both be incomplete. Would it be an overstatement to say it seems like the test and the program have more of a symmetric relationship, rather than an asymmetric one? Thanks for taking the time to explain this!
  - jdlshore 7y ago
    You're welcome! I'm not sure what you mean by symmetric vs. asymmetric relationships, but if you mean that they're developed in parallel, both as first-class citizens, with each informing the other, and each taking about the same amount of time and code, then yes. Or you could also call it a symbiotic relationship.