1. 14

  2. 7

    It’s a bummer this doesn’t reference property based tests, which give you a lot of value IMO.

    1. 5

      I didn’t know what property based tests were: http://blog.jessitron.com/2013/04/property-based-testing-what-is-it.html

      1. 1

        Is this done a lot in non-functional languages? I’m genuinely curious, as this seems like a very powerful way of testing, but I don’t see many libraries outside of the FP side of the yard.

        1. 1

          I know QuviQ (company behind Quickcheck) has a quickcheck for C, I don’t know if that is special though. I’m under the impression it was made for Volvo.

          I’ve heard that there exists Python and Ruby variants, but I’m unsure of how well they work and how much love they’ve been given.

      2. 6

        One of the reasons I really prefer strongly typed languages is that you can slash code and move it around aggressively to clean up style and split things off into other files. Or perhaps change an interface or even dependency.

        If it compiles, there’s a high likelihood it still works.

        I’ve found doing the exact same thing in languages like Python and JavaScript is an absolute nightmare. Here, trivial unit tests would help get coverage of the code, but they are substantially more work than simply using the typed language.

        My tests in typed languages tend to exercise actual data or string input and are much more focused. In dynamic languages, I’d rather not even write tests because it just feels painful and monotonous to test every function.

        1. 2

          I think you need tests even more in a dynamic language… although I tend not to aim for LOC coverage, but business rule coverage. If you can meaningfully change the behavior of your application, it should break a test.

          I don’t think testing getters/setters in dynamic languages is part of sane TDD. And tests - not blind, rabid, fad-driven tests, but thoughtful and carefully selected tests - can give you some of the same security that the type system gives you in Java/C#/etc.

          I’m primarily a Ruby guy, and I write plenty of unit and integration tests… and generally, I find that if refactoring causes me to break so many tests that it’s a lot of work to fix them, then they were either redundant, badly written, testing at the wrong level, or in some other way sub-optimal. As I’ve written more Ruby and more tests, I find less and less often that I’m stepping on my tests when extracting code, refactoring, etc. YMMV.

          Edit: and I like to unit test my JS this way too, with Jasmine.

          1. 1

            Yeah my point, put more succinctly: dynamic languages need more tests but cognitive dissonance makes it very hard for me to do.

          2. [Comment removed by author]

            1. 1

              One of the most interesting remarks I’ve seen about OCaml — which I don’t fully understand — is that using it properly involves “encoding your proof obligations into the type system”. Which is to say, I guess, that you choose the way you use its type system to verify that much of the program’s functionality is correct, too.

              In dependently typed languages, I am given to understand that you can prove arbitrarily complicated things with the type system, but dependent typing systems are not (ever? generally?) decidable. OCaml’s type system is decidable.

          3. 5

            I personally find a test suite composed of granular unit tests to be invaluable when code velocity is high. The tests by themselves do not have high value, but together form a regression safety net.

            Intrigued by the approach of assertions + integration tests. Will be trying this out in the next project.

            1. 3

              Assertions plus integration is what we do for our project. Best thing for velocity. If you are confident enough, do what we do and leave them on in production. Can’t ignore bugs when they prevent your program from running.

              and our project is serious, actual big data. Think petabytes.

              so I highly recommend this. Also suggest white box testing. Throw random data at your program!