Hacker News Reader

That’s funny. I only write tests to prove that the program does what it’s meant to do and not to find bugs.

The goal is to prevent a future programmer, including myself, from breaking any of the declared properties.

Tests don’t prove anything, they just show the intended behaviour. Only full verification proofs show correctness.

Too often I’ve seen “tests show it’s correct” suites horribly fail to provide value when the behaviour changes in a unit of business logic and the brittleness needs to be unwound and replaced with robust assumptions.

For me, it’s all about maximizing quality; which is usually about bugs. For example, I’m currently writing an ONVIF driver. This needs to address hundreds of devices. I only have about ten to test against. They feature a wide range of implementation, but they are, by no means, full coverage. I’m gonna need to mock up some crazy, nonexistent devices to stress a few particular parts of the library. If I can make it work with them, then chances are better than even that it will work with devices I can’t directly test. I use test harnesses to ensure functionality. My test harnesses tend to be huge; often, a lot bigger than actual shipping implementations.

Reply on news.ycombinator.com