Nice writeup! I especially like how the example is something that you ran into in the Real World and not a toy example. One suggestion: you write
While it’s possible to see the bug in the next session, in the code that follows your quote it’s not immediately obvious what the bug is. I think it would be worth saying explicitly “the bug is that it writes ‘123.4’ instead of ‘1.234’”.
Note: The contracts can be enforce with tests. Current thought is to do assert’s where it’s easy and tests where that just clutters things too much. Balance it out based on what’s easy for you.
It seems that one benefit of contracts is that it makes fuzzing a lot more powerful. Instead of just finding crashes, fuzzing will also find contract violations. Do you have any experience with / resources to recommend on combining fuzzing and contracts?
EDIT: looks like contractual has been depreciated and replaced with this.
It does. Property-based and random testing oftdn catch different errors. Using both makes sense. With properties embedded in code, the result is like a breakpoint in a debugger where fuzzing errors go straight to the point where it breaks. Then the benefits during changes/maintenance kick in where the fix is less likely to cause silent breaks.
Far as resources, my mind is blank on it. Chalk it up ik memory loss. Ill make that my next project for research. Ill post the better ones I find within a week or two.
I love unit testing. I’m a passionateTDDer. Few things have been as gratifying as what unit testing has given me–when done right.
A lot of the time, recent converts to unit testing and management think that it’s a guarantee of infalliable code. The idea that 100% coverage is 100% bug free code.
I think the follow on to falling in love with unit testing is being able to identify the right things to test. I believe what makes unit testing “good” is writing the right tests. That’s something that comes with experience but code reviews/having a 2nd, 3rd, and 4th set of eyes look at your code can really help. Even today I struggle picking the right things to test.
I’ve said it before here, but it bears repeating: 100% coverage tells you nothing at all (the tests could be bad) but 90% coverage tells you that 10% definitely hasn’t been tested.