5 ms·

I disagree. Unit and feature testing are vastly overrated for what they do, and their current use is faddishly subscribed to in a seemingly cult like fashion. U

by dylukes 12y ago

I disagree. Unit and feature testing are vastly overrated for what they do, and their current use is faddishly subscribed to in a seemingly cult like fashion. Unit tests are excellent for testing non-stateful behavior of code. That is, they're great for testing contracts, and they have a bit more flexibility than Eiffel style contracts. However, using them to the extent of "returns an Object of this type" is absurdly verbose and pollutes the code base with roundabout information. These sorts of things are best left to a static type system, which is a more specialized and effective system for that portion of validating your code. On the other end of things, tests of more stateful processes or behaviors are better served by E2E testing. There's nothing wrong with using multiple forms of testing. Different tools excel at testing different sorts of things.

mseepgood 12y ago
> However, using them to the extent of "returns an Object of this type" is absurdly verbose and pollutes the code base with roundabout information. I did not talk about unit tests. I do not test stupid things like "returns object of this type". I test functionality (more like integration tests). If the functionality works then things like "returns object of correct type" or "items in collection are treated correctly" are tested implicitly or don't matter. People with ridiculously complex type system programming languages have to write these automated tests as well, because even ridiculously complex type systems like Idris don't ensure the correctness of non-trivial logic.
- andreasvc 12y ago
  Your argument that typing is tested implicitly or doesn't matter is false, because your function might have 73 code paths, of which your test only covers 1. Tests and types are complementary. A test will prove that in at least one case the function does what it should, but a type system can prove that in all cases at least the types are correct. There was a blog post describing this as establishing a upper vs. a lower bound.
  - mseepgood 12y ago
    You have to write tests for the other 72 code paths anyway, because types can't ensure the behavioral correctness of these 72 code paths. Correct types don't help when the behavior can be broken. And when you have to write these tests anyway then you don't need the types anymore.

by dylukes 12y ago

mseepgood 12y ago

> However, using them to the extent of "returns an Object of this type" is absurdly verbose and pollutes the code base with roundabout information. I did not talk about unit tests. I do not test stupid things like "returns object of this type". I test functionality (more like integration tests). If the functionality works then things like "returns object of correct type" or "items in collection are treated correctly" are tested implicitly or don't matter. People with ridiculously complex type system programming languages have to write these automated tests as well, because even ridiculously complex type systems like Idris don't ensure the correctness of non-trivial logic.

andreasvc 12y ago
Your argument that typing is tested implicitly or doesn't matter is false, because your function might have 73 code paths, of which your test only covers 1. Tests and types are complementary. A test will prove that in at least one case the function does what it should, but a type system can prove that in all cases at least the types are correct. There was a blog post describing this as establishing a upper vs. a lower bound.
- mseepgood 12y ago
  You have to write tests for the other 72 code paths anyway, because types can't ensure the behavioral correctness of these 72 code paths. Correct types don't help when the behavior can be broken. And when you have to write these tests anyway then you don't need the types anymore.