4 ms·
> fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things It's understandable how you wouldn't
by lojack 10y ago
> fail to see how a big function should be harder to test than two smaller ones that when combined can do the same things
It's understandable how you wouldn't see this without testing experience. Wrote a quick gist to try to explain it as best as I could. https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37d9b https://gist.github.com/lojack/5a8526e88c759acac3f4f46036a37...
That's a trivial example using pseudocode. But, basically, you'll see that in the longer function example you need 10 test cases to cover all grounds, while in the method thats split apart you need 8. Realistically, I could have further split parseArguments up to simplify those test cases. It seems like a small change, but if you were to add an additional branch to the first method (an if statement) then you'd double the number of tests required. For the longer method thats 10 additional test cases, for the shorter method thats 2.
- jstimpfle 10y agoRealize that both implementations offer the same functionality. You could even say the implementations are basically identical, except for the fact that one gives more "calling surface". So it is is only the "ideal" of 100% branch coverage that misleads you into think you would need more tests. The two branches of the big function don't interact in any way (they could also be paralleized), so 100% branch coverage has no benefit here. In fact you need less tests with the big function if you don't know the context in which the functionality is used, since the surface area is smaller. Another way to look at it is that 100% branch coverage only means all the branches in one isolated function are tested. However, the multiple-functions version calls other functions and the possible branches there are ignored. In other words the interaction with called functions is not tested.