4 ms·
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
by 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 agoYou'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 agoYes, all those things. ("Symbiotic" doesn't quite get at it because it doesn't imply this kind of equality on both sides.) Based on my personal experience and observations of others so far, I think a large fraction of programmers experience unit tests as (a) taking more time to write than the code under test; (b) requiring much more code than the code under test; and (c) relied upon to be correct much more than the code under test. (To be clear, I'm talking about unit tests, not integration or system tests.) In order to understand what you meant by TDD, I needed to unlearn all these things, and I suspect others will need to as well.