4 ms·

If you write unit tests that make assertions that would be caught by a type checker, you're writing bad tests.

• cia_plant 13y ago
  All unit test assertions can be caught by a type checker.
  • crystaln 13y ago
    Assuming you are sarcastically dismissing typed language defenses, as if people promoting typed languages have the position that tests are not necessary.
    • cia_plant 13y ago
      No, I'm simply stating the fact that there are type systems capable of encoding assertions.
  • basman 13y ago
    Your type checker catches array indexing bugs? Impressive.
    • virtualwhys 13y ago
      No, but Scala encourages FP, so when you: val fooList = List(1,2,3) fooList.map(...) you'll _never_ hit the types of bugs you're referring to. If you fooList(3), then of course you're hosed, but that's not the type checker's fault ;-)
    • kasey_junk 13y ago
      I don't agree even with the sentiment of the original post, but there is an argument that while you can't get rid of array indexing bugs with a type checker (contracts might help here) you can design your collection types such that things like indexing above or below an array are compile time caught, as is indexing into the "wrong" array location. Whether it is worth the trouble to do this in the type system probably depends on how good your language's type system is and how expensive array indexing bugs are to catch/fix.
    • nousernamesleft 13y ago
      Yes. http://www.ats-lang.org/ http://www.ats-lang.org/
    • AnimalMuppet 13y ago
      Actually, in the original (circa 1968) Pascal, it did. In Pascal, the size of an array was part of the type of the array. IIRC, You simply could not write an array index out of bounds bug. This made it a somewhat reasonable choice for a medical device, where an array index out of bounds could be catastrophic. However... You also could not create a variable-sized array. There was no way even to talk about the type of such an object. (Yes, I ran into that professionally once.) I think this is why Turbo Pascal (and maybe others?) softened that.
• crystaln 13y ago
  If you don't understand why a dynamic language needs more tests than a typed one, you probably haven't worked with typed languages. The difference is dramatic and clear. Just one example, code coverage must be 100% for a dynamic language in order to avoid runtime catastrophic failures due to simple typos - like letter transposition. Sure, 100% test coverage is a nice goal, but it's rarely met. In a typed language, you can be 100% sure this won't happen with zero tests.
  • jcrites 13y ago
    That's a great point! It's also what makes refactoring so much easier. If I need to rename a method obj.f() to obj.g(), then I can do so safely knowing that no lingering references to f() remain in my code base (else they would fail to type as f() is no longer a valid method). As you say, 100% code coverage is unrealistic. Having maintained large applications in both static and dynamically typed languages, I feel that statically typed programs are far easier to manage for this reason - that if my code compiles then it means there exist no errors of a certain trivial class, such as typos and references to classes or methods that have been removed. There are still other errors to worry about, but mitigating those errors can be done effectively without needing to approach 100% code coverage.