Cobertura Coverage and Assert Keyword

Question

My string coverage for unit tests measured by Cobertura suffers because I have assert statements that are not covered in the tests. Should I test assert ions and is there a way to get Cobertura to ignore them so that they do not affect my test coverage?

Answer 1

The coverage of the lines of your Java assert should simply be covered by running your test suite with statements included, that is, providing -ea as a jvm argument. If you do this, you will see that cobertura easily reports 100% of the line if the rest of your lines are also covered.

However, assert lines will still be colored red, indicating low light. This is because your statements are usually always true, so you never end up in a false branch.

Thus, branch coverage in Cobertura is corrupted using assert , because assert lines will have 50% branch coverage, making the total percentage of branch coverage difficult to interpret (or useless).

Clover has the nice ability to ignore assert when calculating coverage. I have not seen this feature in any open source Java coverage tool.

If you use design -style statements behind a contract , there is no need to add tests that make your Java assert fail. As a matter of fact, for many statements (for example, invariants, post-conditions) you cannot even create objects that could lead to their failure, therefore such tests cannot be written. However, you can use invariants / postconditions to get test cases that implement their boundaries - see Figure Robert Binder invariant boundaries . But this will not lead to the failure of your statements.

Only if you have a very complex precondition for this method, you may want to write a test aimed at making the precondition unsuccessful. But then rethinking your precondition may be a better idea.

Answer 2

There, a function request (1959691) is already registered for Cobertura to add the ability to ignore assert strings; feel free to watch it if implemented and add a comment to the page if you think this is a good idea. It’s a shame that none of the open source distribution tools support this, as I definitely think statements are a good idea, but testing them is usually impractical / possible.

Answer 3

Code coverage is a tool that can improve your testing; it is not proof of the correctness of your tests. You get value from this by striving to have 100% coverage of the code, looking at what is not covered, and thinking about how to improve your tests.

Finding that there are disclosed assert statements is just an example where you should call: “Ok, no need to cover this.” Similar examples for this are macro tracing and debugging code, which adds hidden "if statements" that are never considered.

I think what you don't like about your answer is that you like the minimum code coverage requirement for your code; I ran into the same issue with some of my projects. If one should not lose coverage data, one solution should have a “coverage assembly” where problematic statements (statement, trace, etc.) are replaced by empty ones (say, using a macro or linker magic), but I think this is usually the best compromise to accept is not perfect coverage.

Good luck.

Answer 4

Presumably you are using statements to test preconditions or some other set of conditions. Think about whether your situation looks like Exceptions for arguments should be checked with a module .

In any case, I expect that eventually you will try to determine whether the branches of the negative paths of these operators should be checked.

Yes, be sure to check them out. Your statements themselves are the logic of your assumptions, and it is a good thing to check that your security statements prevent / protect the scenarios that you think they are doing.