3 ms·
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 k
by lectrick 11y 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.
- quietplatypus 11y agoThis 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.
- lectrick 11y agoI 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.
- tome 11y ago> 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.
- prodigal_erik 11y agoThere is always a unit test which could catch any type mismatch. The problem is that every type declaration implies a set of unit tests (probably an unbounded set!) and in practice it's not likely you'll actually write enough of them.