4 ms·
From a bit philosophical point of view a program is the specification of what the computer should do. Unit tests and type annotations both are some kind of chec
by nadam 16y ago
From a bit philosophical point of view a program is the specification of what the computer should do. Unit tests and type annotations both are some kind of checksums.
Generally I am for brevity: the program should be short. So I prefer that the 'checksum' also should be short. Unit testing is a really elegant and good tool if you can test a quite big chunk of functionality with a short test. If the test is for example longer than the tested functionality then its value is more controversial. Ok, for extremely important code, like the control of an airplane, put there as much redundancy in the checksum as you think is needed. But otherwise, it can be questionable.
The issue is quite similar with static typing. I am a static typing fan, but dynamic language guys always complain that you have to type too much in static languages. And they are right to some extent, although better static languages have good type inference, so it is not that big of an issue.
In fact I don't really understand dynamic language guys. They always state that they like terse code, but with modern statically typed languages like Scala you really don't have to type much more than in dynamic languages. The difference is negligible compared to that those same guys are usually unit testing fans and their unit tests sometimes really make the code base significantly bigger.
TL;DR;: I value terseness, and I prefer to use both static typing and unit tests only if it does not increase the code size significantly.
- jefffoster 16y agoWhen I'm working in a static language such as Haskell I very rarely write traditional unit tests, instead preferring to use QuickCheck (http://en.wikipedia.org/wiki/QuickCheck http://en.wikipedia.org/wiki/QuickCheck). I like the adversarial nature - I specify invariants and I challenge the computer to prove me wrong! This seems more likely to find bugs than me writing my own tests. Wanting to find bugs seems to be an important factor in writing quality tests. It's easy to write soft tests when the same person writes the code and does the test. Maybe that's why pair programming and TDD seem to go well together, as the other person is more motivated to try and break your code?