Comment by lectrick
10 years ago
As a developer, what this means to me is:
For every piece of code you write, there should be a unit test covering it that you can run fairly instantly with 1 keypress which catches at least internal-consistency errors. (Integration tests would cover external-consistency errors, but when you're refactoring/adding/deleting code, internal-consistency is violated far more often than external consistency, in my experience.)
Once you experience this for yourself, you will NOT want to go without it. It allows you to IMMEDIATELY get back to coding without waiting for test runs to finish and without creating bugs unknowingly that you only catch much later.
This is why I love Haskell---the check, though approximate, is built in to the language as the type checker. Pair it up with the speed Haskell coder's best friend, "undefined", and you can be just 40 characters into writing part of a method and check it right there on the spot, getting into a good flow.
I see that appeal of Haskell, and I think the strict focus on typing does catch many possible bugs... but I don't think it catches all the types of bugs that an actual unit test would, so I'm almost afraid that it's leaned on a bit too much.
> but I don't think it catches all the types of bugs that an actual unit test would
You are correct. Likewise types can catch some bugs that unit tests cannot.
1 reply →