I am measuring the code coverage in my project using the EclEmma plugin for Eclipse. This involves running the coverage for the whole project. But due to some dependency issues tests in some packages are failing altogether. When the coverage for these package is taken individually, the tests run properly and the package is showing the coverage correctly.
Is it possible to get a Coverage report, by running the coverage for each package separately and then merging these reports into one.
Or Alternatively, are there any other free plugins which offer the above capability.
Note: Modifying the test methods to remove the dependency may not be possible due to logical and size constraints.
It's been a while since I shifted to IDEA, but I seem to recall that there was an option (as in "button in the EclEMMA view") to merge several coverage runs.
A visit to http://www.eclemma.org/ confirms this - look for "Merge Sessions". Also:
http://www.eclemma.org/userdoc/sessions.html and
http://www.eclemma.org/userdoc/coverageview.html
It is the button to the right of the "double-X" Remove all sessions button.
Cheers,
Related
I am attempting to generate code coverage for a jar that is in my library. I have a suite of tests that uses this jar and I would like to see how much coverage I am getting with my test suite. In Intellij's run/configuration menu, even if I manually specify to include all the classes in the jar, ex. "com.my.jar.*", I get 0% code coverage. In Eclipse, I was able to easily select the jar, hit 'Coverage', and get accurate results. Has anyone else converting to Intellij from Eclipse experienced the same issue?
I got stuck on this too - I was able to get it working in Eclipse instead of Idea
Does eclipse has a feature or plugin that shows the used code branch for an execution?
I known about coverage plugins for junit test, but I would like one for normal runtime execution instead of unit tests.
The EclEmma code coverage plug-in is not specific to JUnit executions. Measuring code coverage is an added launch mode, like Run, or Debug.
https://www.eclemma.org/userdoc/launching.html
Recently I've upgraded SonarQube from 3.5 to 4.5.4 (LTS) and now there are a few users complaining that there are some reports missing on their project dashboards. The reports/numbers missing widgets are: lines of code and complexity. Unit tests coverage displays nothing. Other widgets (like technical debt, issues, directory tangle index) display 0 which also is suspicious. The project is in Java using the Sonar way profile.
The user does:
mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install
mvn sonar:sonar -Dsonar.login=login -Dsonar.password=***** -Dcom.sun.jndi.ldap.connect.pool.prefsize=0 -Dcom.sun.jndi.ldap.connect.pool.timeout=3600000
The sonar:sonar step shows "0 files indexed".
The log is huge so I don't want to paste it here. I could not find anything helpful in it. What do I need to do to have all reports I used to have?
I have a test project where most of the missing data is displayed "out of the box".
Starting with version 4.3, SonarQube no longer runs automated tests. It expects Jenkins/CI system to run the tests, create the JUnit/PMD/Jacoco/Clover etc. reports, and then tell SonarQube where to find them. (In older versions of SonarQube, this behavior could be achieved by setting the "reuseReports" flag to true.)
If the build is not configured to generate the reports, it will need to be adjusted to do so.
I'm working on a project that has a lot of legacy code that is not covered with tests.
Is there any way that I could set up the integration server to check that all new commits have a minimum amount of tests (say, coverage is >70%)?
Essentially, I see two options:
Somehow set up the CI server to fail the build when the committed changes are not covered with unit tests. This will ensure that every piece of new code will have tests and that tests for the legacy code will increase with each change.
Set a coverage threshold for the whole project and fail the build if the coverage percentage decreases after a commit. The problem with this is that if I delete a class containing 100 instructions and add a new class with 50 instructions the coverage percentage will go up without me writing any tests.
I like option 1 more because it forces changes in legacy code to be unit tested. This should increase the overall test coverage.
Right now we're using Jenkins as our CI server and JaCoCo for test coverage. Maven is used for building the project and SVN is our main source control.
I know you can configure Jenkins to verify that there is at least one test file as part of the commit. That would not assure good test coverage, but at least you would know there was some kind of test related changes.
Some coverage tools (like cobertura) support excluding packages. This way, you can exclude all the old code (assuming it can be pattern matched) and have cobertura check only new code (which covers new commits).
I hope this helps.
For option 2, you can use the Jenkins JaCoCo plugin to track the code coverage for each build and set the build result to passed or failed depending on the coverage metrics.
I like option 1 better, too, but I don't know of a built-in way for Jenkins to do this. It should be fairly easy (at least at the class level) to post-process the coverage data and combine it with the SVN revision info, something like:
Parse the JaCoCo output files and find classes that have 0% coverage
Get the file(s) that changed for this build from the SVN revision details (Jenkins makes the revision numbers available in environment variables, SVN_REVISION if there is only one for this build or SVN_REVISION_1, SVN_REVISION_2, ... for multiple)
Print an error message if any of the changed classes have 0% coverage
Use the Jenkins Text Finder plugin to fail the build if the error message is printed.
This isn't a full solution, it gets trickier for new methods or lines that aren't covered by tests. Gives me an idea for a new Jenkins plugin ;-)
I have built a tool which does exactly this
https://github.com/exussum12/coverageChecker
You pass in the diff of the branch and the cover test output from the tests. The tool works out which lines in the diff are also in the clover file. and fails the build if less than a certain percentage
to use
bin/diffFilter --phpunit diff.txt clover.xml 70
to fail builds when less than 70% of the diff is covered by a test
I can add other formats if needed
Edit
I have added jacoco
Bin/diffFilter --jacoco diff.txt jacoco.xml
I installed EclEmma for its source annotation abilities relating to code coverage, how it highlights code with various colors based on whether or not that code is hit during execution. I intend to use this information for debugging purposes. The default install adds a "launch with coverage" button, which is what I want. This works perfectly for the entry point into the program; that entire source file gets beautiful coverage information smeared all over it. Unfortunately none of the other project files get the same treatment.
When I go over to the new coverage tab I see my source folder structure and all of my source files are listed along with coverage percentages. This is nice, but I would really like it to add the coverage annotations to my other source files so that I can review code coverage line by line in the rest of my project. Presently even clicking on them in the coverage tab with the percentage sitting directly to the right opens the plain unannotated source file (well, unannotated besides Eclipse's normal annotations for Java code). How can I get EclEmma to add source code coverage information to all of my source files, not just the one containing the point of entry to the program?
I suspect that there is a simple fix that I am missing, but the best I can get from the relevant documentation is how to change the color of the annotations.
For reference I am using Eclipse 4.2.1 for Java development. My EclEmma installation is the one from the Eclipse Marketplace.
Thank you for your time,
-- Techrocket9
For unknown reasons the issue seems to have resolved itself. I can only conclude that the EclEmma does not require alteration to display source annotations for other files, and that a bug in my particular Eclipse install triggered the issue and that the bug was fixed in an Eclipse or EclEmma update.