6 ms·
You write unit tests and ensure 100% code coverage. That sounds like a lot of extra effort; it would be nice to automate the testing a bit. Maybe some sort of
by camccann 17y ago
You write unit tests and ensure 100% code coverage.
That sounds like a lot of extra effort; it would be nice to automate the testing a bit. Maybe some sort of simple declarative system to check that the code obeys certain constraints. Ideally, you could make your auto-test system clever enough to actually deduce a lot of the constraints itself, based on the structure of the code--you'd really save time that way! Then you could focus your effort on just testing the things your auto-testing system can't check.
I wonder if anything like that exists?
- omouse 17y agoOnce you have the constraints, or contract, in place, you probably don't even need the unit-tests because the function will not work at all unless the contrainsts/contract are met.
- camccann 17y agoWell, for a program of sufficient complexity there'll probably always be some aspect that can only be checked easily by unit testing--if only stuff where the program works as intended but the programmer's intent was mistaken.
- omouse 17y agoCould you give an example of that? I'm not sure what you mean. If the programmer's intent was mistaken, then the program needs to be re-written. You don't really need unit-tests for that, you just need to think about it. Maybe the unit-tests force you to think while writing them?
- camccann 17y ago"Force you to think" is basically the idea, yes. The goal is to catch places where your high-level conceptual understanding of the task to be accomplished doesn't match the lower-level model of "how to get from here to there" you've mentally constructed, usually at weird corner cases. There's roughly three places where a programmer can make a mistake--understanding a task to be done, creating an algorithm to perform the task, and describing the algorithm to the computer. Type checks help insure that the algorithm you intended to code is what you actually coded; tests can help ensure that the algorithm you coded actually performs the task you think it does. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- D. Knuth
- gnosis 17y agoHmm... your idea is starting to sound suspiciously like a statically typed language with automatic type inference.
- DenisM 17y agoIt might be more effort, but having tried it I can tell you it's not that much effort. It also has tangible benefits in that it forces you to think through the edge conditions, leads to better interface abstractions and reduces fear of making changes. I don't want to turn this into religious thing, but if you never tried this I encourage trying it out at least once. As to your question, that sounds very much like Haskel. They even have a search engine that lets you search library functions by type signature, and often time you find the right function just based on that.
- fauigerzigerk 17y agoThe problem is that 100% code coverage is not nearly enough. Take this Python function: def f(x, y): return x + y and this test function: def test_f(): assertEqual(2, f(1, 1)) There you go, 100% code coverage. Unfortunately we have covered next to 0% of what could possibly go wrong here.