Tag Info

New answers tagged

3

Above all, you need to have and analyse combined (total) coverage. If you think of it, this is the most natural way to properly prioritize your risks and focus your test development effort. Combined coverage shows you what code is not covered by tests at all, ie is most risky and need to be investigated first. Separate coverage reports won't help here, as ...


2

You don't mention your testing tool. Many have "combine" functions that let you aggregate the results of multiple runs or suites. If you want an aggregate coverage metric, explore the combine feature in your coverage tool. Now, can we talk about the elephant in the room? There is no spoon. And there is no "total coverage percentage." At least, no simple ...


6

Of course it is OK! You always need functional/integration test that exercise the complete code path. And complete code path in this case means including evaluation of the generated code. That is you test that parsing x = 2 + 3 * a produces code that if run with a = 5 will set x to 17 and if run with a = -2 will set x to -4. Below this, you should do unit ...


4

Unit tests allow you to pin point specific items that break and where in the code they broke. So they're good for very fine grained testing. Good unit tests will help decrease debugging time. However, from my experience unit tests are rarely good enough to actually verify correct operation. So integration tests are also helpful to verify a chain or ...


21

You're going to find yourself writing a lot more tests, of much more complicated, interesting, and useful behavior, if you can do so simply. So the option that involves var input = new Parser().ParseStatement("x = 2 + 3 * a"); is quite valid. It does depend on another component. But everything depends on dozens of other components. If you mock something ...



Top 50 recent answers are included