3 ms·
> The rationale, of course, is to feed in values that test each code path That's the absolutely wrong way to test a function. You want to test a function so _a
by sklivvz1971 9y ago
> The rationale, of course, is to feed in values that test each code path
That's the absolutely wrong way to test a function. You want to test a function so _as the implementation changes, the same output follows the same inputs_.
Counterexample: I might refactor that function without those code paths (e.g. write `x*sign(x)` instead). Do I need only one test now?
Morale: DO NOT TEST IMPLEMENTATIONS
- ghettoimp 9y agoIf none of your test cases ever hit some lines of your functions, it seems pretty clear that your tests are missing functionality. Of course, hitting each line with a single test doesn’t guarantee your tests are “sufficient,” but pragmatically it seems like a reasonably good and easy to understand starting point.
- dang 9y agoCould you please not use uppercase for emphasis in HN comments? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- taeric 9y agoI think you are viewing it not as an iterative process. If you have code that isn't covered by a test, then by all means feel free to refactor such that that code isn't needed. If you can look at it and see the code is needed, then you are clearly lacking a test that shows why it is needed. You can let both ends inform the next step.
- adrianratnapala 9y agoThe (rhertorical) question the author was asking is how would a machine back out a reasonable set of test cases from the source code. The fact that this code branches conditionally on the sign of the input is a hint that the test set should worry about sign. Tests derived this way will still be useful if the implementation were changed to something that didn't branch. I suspect though that we shouldn't get too stuck on the testing thing. The author only asked the question to introduce thinking about how to abstract expectations behviour out of concrete code. Test generation is only one of the uses he cites.