I am currently dealing with a legacy Java Maven project that I need to alter. I have ran a test coverage report with cobertura and can see that the logic I have to change is currently covered by a test. Given that the code base is tens of thousands of classes in size, that the complexity of many of the classes and tests is very large, and that there they are not testing their code unit by unit opting for sort of semi-integration tests...I will have no luck manually tracking down which tests are providing this coverage.
What I'd ideally have is some way to find out that line x of source class y is covered by method t of test class r.
Is there a way with cobertura or some other tool (hopefully a Maven plugin) that I can view the tests which actually cover each LoC?
Put a breakpoint in your method, execute your test in debug mode, and then look at the call stack when the VM suspends.
Related
Hi recently we have done the unit testing for the entire project using mockito framework. My project is on Java spring rest project. But the coverage is below 35%. Need to improve the unit testing coverage.
1. Want to remove the unneccesay package from the code coverage, like test packages and beans class
2. Do we need to write the unit test case for the controller class and generated class from the tools.
I will be very grateful, if you can help me.
Test classes and packages are not counted in test coverage, if they were, how do you test the code that tests the code etc..
When you run coverage it should only run over src/main/Java etc.
Controller classes should be tested, when you call a method, is the correct delegated class and method called?
Generated classes, if from xml using jaxb etc do not need to be explicitly tested if they are just plain old Java objects with getter, setters and fields. It's likely they will be tested via another class that uses these objects and calls their methods. These classes will be generated/compiled before your tests run so will be available- make sure you aren't committing generated classes to your code repository.
You may want to consider testing the behaviour of third party libraries you depend on. This way you can instantly see if any updates to libraries may cause issues, but this should be from a high level.
You need to not start ignoring classes, but instead run a code coverage tool and see what's uncovered, and get those unit tests up to par. Test your failure cases, too!
The test packages should NOT be part of the 35%, so removing them is not going to help. None of the coverage tools I know of consider test packages.
As for generated classes - most likely not, but again, run a code coverage tool and you'll quickly see what needs to be covered.
If you use IntelliJ then coverage tools are built in:
https://www.jetbrains.com/help/idea/2016.2/code-coverage.html
Eclipse uses plugins, one is:
http://www.eclemma.org/
There are more if you google.
I prefer Sonar:
http://www.sonarqube.org/
But whatever tool you use, that's the way to go.
I'm using Junit with Eclipse. I have created test cases for few of the methods in my project. Is there any way/plugin to find the list of classes for which the test cases have been created(so that I need not manually check whether test cases created for all methods)?
You should look into using Code coverage tools, that are designed to do exactly this by telling you for instance:
which lines are covered by your tests
which branches of loops, ifs, switches, etc. are covered by your tests
More unit plug-in decorates all classes for which test classes are written.
Check here.
Using code coverage tools:
If used code coverage tools, then user has to run this(Ex:Eclemma) tool again and again to cover all use cases and merge the results of each run to check the method coverage.This takes more time.
Even this procedure is automated then also user has to open all source files to check whether the method is covered or not. See coverage view.
If the method is marked as 100% coverage that doesn’t mean that test case was written for that method separately. Because other method may called this method internally.
So using code coverage tool it is not possible to decide whether test cases were written for all the methods of all the classes.
I couldnt find this info anywhere. In order to get code coverage calculated using a plugin (like Jococo, Cobertura..etc) Do I need to run all the unit tests before? These look like relevant tasks, But still I think Code coverage should not be dependent on running unit tests before hand, unless coverage plugin really relies on the Junit
You do not need to run tests beforehand. The coverage tool instruments the code (if required), runs the tests (or your main) and then reports the stats back to you.
Having said that, if your code relies of fancy reflection/bytecode manipulation, it may be a good idea to run tests beforehand, just to make sure that failures reported during the coverage scan the the instrumentation's fault and not "real" test failures.
Is there a tool for Java which, given a set of JUnit tests, and a class to test, will tell you which lines of the class are tested by the tests? ie. required to be present for the tests to run successfully. I don't mean "code coverage", which only tells you whether a line is executed, but something stronger than that: Is the line required for the test to pass?
I often comment out a line of code and run a test to see if the test really is testing that line of code. I reckon this could be done automatically by a semi-smart tool (eg. something like an IDE that can work out what can be removed from a method whilst keeping it compilable).
There's an open source mutation-testing tool called Jester that changes the lines of your source code, then runs your tests, and reports whether your tests passed anyway. Sounds closer to what you're looking for than code coverage tools.
Jester is a test tester for testing your java JUnit tests (Pester is for Python PyUnit tests). It modifies your source code, runs the tests and reports if the tests pass despite the changes to the code. This can indicate missing tests or redundant code.
WRT the discussion about whether these tools are needed in a pure TDD project, there is a link on the Jester project webpage to a posting about the benefits of using Jester on code written during a TDD session (Uncle Bob's infamous bowling TDD example).
What you are looking for might be referred to as mutation testing. While mutation testing won't tell you which lines of code are required to pass, per se. What mutation testing does is modify your source code looking for changes it can make to your code but your test still passes. E.g. changing
if (a < b)
to
if (a >= b)
and seeing if the test still passes. This will highlight weaknesses in your test.
Another java library for mutation testing is jumble.
I use emma for most of my projects. i included it in my ant build file and it generates html files for the reports
two other coverage projects i read about but haven't tried yet are clover or cobertura
I love cobertura, because the generated reports are IMHO the most beautiful. And it has its own ant target!
In comparison to emma, it has also branch coverage, not only line coverage, which is misleading very often.
We use use junit for unit testing our java code. Today we use cobertura to get coverage numbers. It does not have an easy way of getting per test coverage number. Is there a tool to get per test code coverage - commercial/free?
(cobertura has a patch to get per test coverage numbers, out of date with latest cobertura).
we used clover to good effect. we wrote some ant tasks that allowed us to run it from a dev box, so we could view the coverage numbers locally, and we also integrated it into our continuos integration so we had a site for the official number.
http://www.atlassian.com/software/clover/
the only issue we had was it is a memory hog....
Emma provides detailed reports by overall/package/class for block and line coverage.
The obvious way to do this is, run one test and dump the test coverage data. (In fact, this is the only way to do this).
Our SD Java Test Coverage Tool has explicit DumpVectors and ResetVectors procedures that can be called anytime. By adjusting the unit test framework to just call these two procedures between tests, you can get one test coverage vector per unit test.
The display tool will display any individual test coverage vector. It can also give you the union of the entire set (as if you had run all the tests) or compute how one test overlaps with another.