1. 9

  2. 3

    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

    Today, I received a bug ticket. For a simple Javascript feature I wrote a few months ago. I saw the description of the ticket, took one look into the code and I was furious at myself. I could see my error right away and it was a stupid one.

    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’”.

    1. 2

      Good job. You learned the habit quick. Next thing I recommend checking out is Design-by-Contract. It’s another method that doesn’t take much effort for benefits you get, some of same as thorough testing. You can even derive tests from the DbC specifications. That’s commonly-called spec-based or property-based testing. Or you just leave the DbC properties in there with a JavaScript fuzzer of some sort basically trying to hit them randomly to cause a failure. I advise both if tooling exists. A big, side benefit is it catches problems during extensions or refactoring right at the source (i.e. interface that failed).



      I have no idea what tooling exists for this in JavaScript or even how to evaluate that as a non-JSer. I did think this result sounded cool, though, with a clean look:


      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.

      1. 2

        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.

        1. 2

          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.

      2. 2

        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.

        1. 2

          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.