3 ms·

> First, technically returning 9 for a test of add(4,5) is correct. Your tests define what the function does, not the name. If you are thinking "a correct add a

> First, technically returning 9 for a test of add(4,5) is correct. Your tests define what the function does, not the name. If you are thinking "a correct add adds all numbers", then that isn't wrong, but it is bringing your tacit world knowledge into the code without that knowledge being expressed in the code. And that's Not a Good Thing™. How do you feel about just starting with tests that are actually more of a specification? For example, I'm starting to feel that unit tests aren't something we should be writing, but are something we should be generating. We should be writing things like QuickCheck specifications. So the first test I'd probably write is: given x. y. add(x, y) == x + y This is a specification that is essentially tested against a "model" (native addition, in this case).

mpweiher 8y ago
> How do you feel about just starting with tests that are actually more of a specification? Tempted and conflicted. Yes, it's tempting, because "yay, more general and comprehensive", the mathematician inside me says. On the other hand, the beauty of these sorts of tests is often precisely their concreteness/specificity. Tests should be so simple that their correctness is obvious by inspection. (One of my problems with specifications was always that to me it was no clearer that the specification captured what I wanted than that the code did). The other side of the equation is that although theoretically such concrete tests are seriously flawed, because they only test one set of values, in practice that is actually usually quite sufficient. > we should be generating Again, sounds very reasonable, but now you have to trust (a) your generator and (b) your specification of those tests. I'd rather have a concrete test. Now I do think there is some use for this sort of thing, for example in ferreting out edge cases that you might otherwise miss. I wouldn't want to rely on it.

mpweiher 8y ago

> How do you feel about just starting with tests that are actually more of a specification? Tempted and conflicted. Yes, it's tempting, because "yay, more general and comprehensive", the mathematician inside me says. On the other hand, the beauty of these sorts of tests is often precisely their concreteness/specificity. Tests should be so simple that their correctness is obvious by inspection. (One of my problems with specifications was always that to me it was no clearer that the specification captured what I wanted than that the code did). The other side of the equation is that although theoretically such concrete tests are seriously flawed, because they only test one set of values, in practice that is actually usually quite sufficient. > we should be generating Again, sounds very reasonable, but now you have to trust (a) your generator and (b) your specification of those tests. I'd rather have a concrete test. Now I do think there is some use for this sort of thing, for example in ferreting out edge cases that you might otherwise miss. I wouldn't want to rely on it.