sonar coverage reports for multiple java unit test reports - unit-testing

i have a java project called Customer, under this i have another 8 modules, among these 5 modules have junit test classes and have separate ant build files for each modules. I have created(generated unit test reports) jacoco.exec for each project, now, i like to combine these 5 modules' unit test reports into one report and display (or) display unit test reports for each module wise in sona coverage section. Can you please provide any suggestion for this.
Thanks,
Joseph

What you want to do is read each module's test report. You can do that with multi-module project configuration. It will probably be most straight-forward if you handle it all from your main build.xml. I've not tested this from Ant, but something like this should work
<property name="sonar.projectKey" ...
<!-- all normal properties here -->
<property name="sonar.modules" value="module1,module2..." />
<property name="module1.sonar.jacoco.reportPath" value="...
Note that if the Jacoco reports are all in a standard location, you may not even need to specify them because child modules inherit their parents' properties. The docs for multi-module project configuration aren't written with Ant syntax in mind, but you should be able to work through that as long as you keep this in mind from the SonarQube Scanner for Ant docs:
The SonarQube Scanner for Ant is an Ant Task that is wrapper of SonarQube Scanner, which works by invoking SonarQube Scanner and passing to it all properties named following a sonar.* convention. This has the downside of not being very Ant-y, but the upside of providing instant availability of any new analysis parameter introduced by a new version of a plugin or of SonarQube itself.

Thanks a lot. again to Ann.. It works to me, my issues resolved(coverage and multiple languages for each module) after added separate module for each sub project in sonar-project.properties as mentioned below.. getting 'coverage' results for modules in Sonarqube..
# Modules
sonar.modules=common,help,mobile,partners
common.sonar.projectBaseDir=C:/dev/workspaces/hg/customer
common.sonar.sources=common/src/main/java,common/web
common.sonar.tests=common/src/test/java
common.sonar.binaries=common/bin
common.sonar.junit.reportsPath=common/test/reports/junitreport
common.sonar.surefire.reportsPath=common/test/reports/junitreport
common.sonar.jacoco.reportPath=common/coverage/common.exec
help.sonar.projectBaseDir=C:/dev/workspaces/hg/customer
help.sonar.sources=help/src/main/java,help/web
help.sonar.tests=help/src/test/java
help.sonar.binaries=help/bin
help.sonar.junit.reportsPath=help/test/reports/junitreport
help.sonar.surefire.reportsPath=help/test/reports/junitreport
help.sonar.jacoco.reportPath=help/coverage/help.exec

This worked for me:
sonar.modules=common,help
sonar.sources=./src/main/java
sonar.binaries=./target/classes
sonar.tests=./src/test/java
sonar.junit.reportsPath=./target/surefire-reports
The path should be relative because sonar automatically navigates to the basedir/module_name/target/surefire-reports

Related

How Do I Setup SonarQube cfamil.gcov Correctly?

I cannot get coverage reporting to work within SonarQube. I have a C++ project for which I am using the build-wrapper-linux-x86-64 along with the sonar-scanner. The basic static analysis for the source code seems to work but there is nothing about test code coverage reported within SonarQube.
As part of the same workflow I am using lcov and genhtml to make a unit test coverage report, so I am confident that most of the code coverage steps are being correctly executed. When I manually view the .gcov files I can see run counts in the first column, so there is data there.
I have my code organised into modules. The sonar-project.properties file includes the following:
# List of the module identifiers
sonar.modules=Module1,Module2
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=./Sources,./Tests
HeliosEmulator.sonar.sources=./Application,./Sources,./Tests
sonar.cfamily.build-wrapper-output=build_output
# Existing reports
sonar.cfamily.build-wrapper-output=build_output
#sonar.cfamily.cppunit.reportsPath=junit
sonar.cfamily.gcov.reportsPath=.
#sonar.cxx.cppcheck.reportPath=cppcheck-result-1.xml
#sonar.cxx.xunit.reportPath=cpputest_*.xml
sonar.junit.reportPaths=junit
I would also like to get the unit test results displayed under the Sonar tools. As I am using the CppUTest framework I do not have an xunit or junit test output at present though. This can be dealt with as a separate issue but as I am unable to found much documentation of how to use the cfamily scanner online I do not know if the tests not being listed is relevant.
I had forgotten to setup my CI system correctly. The .gcov files did not exist for the job that was running the sonar-scanner. They only existed in the testing job that generated the coverage report. No files in the scanner job mean it cannot make a coverage report.
When I set the GitLab CI system I am using to keep the .gcov files as artefacts the coverage reporting suddenly started working.
The .gcov files were generated by a test job and need to be transferred to the sonar-scanner job via the artefact store. This is because GitLab CI does not share a work area between dependent jobs and you have to explicitly say what files must be copied.

WebStorm run all dart unit tests

In WebStorm 11 I want to create a run configuration which runs all dart tests in my project.
However there is no option to do this in the "Dart Test" configuration template. The only options are:
Test Kind: All in file, Test group, single test
Test file: must point to a .dart file, otherwise I get "Dart file is not found"
VM Options (text input)
If I point WebStorm to a single test file this command gets executed in the test window:
C:\path\to\dart\bin\dart.exe --ignore-unrecognized-flags --checked --trace_service_pause_events file:\\\C:\path\to\dart\bin\snapshots\pub.dart.snapshot run test:test -r json C:/path/to/project/test/someclass_test.dart
I don't want to create a run configuration for every unit test class I write, there must be a better way.
Currently I prefer to navigate to the project directory and just run
pub run test:test
This runs all tests which live in files ending with _test.dart which is perfectly what I want. More info here: https://github.com/dart-lang/test#running-tests
Is there no such option in WebStorm for dart developers?
Accordingly to WEB-14747 ticket this functionality is already implemented for the next major version.
You can try latest EAP build of WebStorm v12 here.
I guess that's currently not supported.
The feature to run tests this way is quite new anyway.
If you think this feature is important, lease create a feature request in https://youtrack.jetbrains.com/issues/WEB

Grails test-app classpath

I'm trying to use test support classes within my tests. I want these classes to be available for all different test types.
My directory structure is as follows;
/test/functional
/test/integration
/test/unit
/test/support
I have test helper classes within the /test/support folder that I would like to be available to each of the different test types.
I'm using GGTS and I've added the support folder to the classpath. But whenever I run my integration tests running 'test-app' I get a compiler 'unable to resolve class mypackage.support.MyClass
When I run my unit tests from within GGTS the support classes are found and used. I presume this is because the integration tests run my app in its own JVM.
Is there any way of telling grails to include my support package when running any of my tests?
I don't want my test support classes to be in my application source folders.
The reason that it works for your unit tests inside the IDE is that all source folders get compiled into one directory, and that is added to your classpath along with the jars GGTS picks up from the project dependencies. This is convenient but misleading, because it doesn't take into account that Grails uses different classpaths for run-app and each of the test phases, which you see when you run the integration tests. GGTS doesn't really run the tests; it runs the same grails test-app process that you do from the commandline, and captures its output and listens for build events so it can update its JUnit view.
It's possible to add extra jar files to the classpath for tests because you can hook into an Ant event and add it to the classpath before the tests start. But the compilation process is a lot more involved and it looks like it would be rather ugly/hackish to get it working, and would likely be brittle and stop working in the future when the Grails implementation changes.
Here are some specifics about why it'd be non-trivial. I was hoping that you could call GrailsProjectTestCompiler.compileTests() for your extra directory, but you need to compile it along with the test/unit directory for unit tests and the test/integration directory for integration tests, and the compiler (GrailsProjectTestCompiler) presumes that each test phase only needs to compile that one directory. That compiler uses Gant, and each test phase has its own Grailsc subclass (org.grails.test.compiler.GrailsTestCompiler and org.grails.test.compiler.GrailsIntegrationTestCompiler) registered as taskdefs. So it should be possible to subclass them and add logic to compile both the standard directory and the shared directory, and register those as replacements, but that requires also subclassing and reworking GrailsProjectTestRunner (which instantiates GrailsProjectTestCompiler), and hooking into an event to replace the projectTestRunner field in _GrailsTest.groovy with your custom one, and at this point my brain hurts and I don't want to think about this anymore :)
So instead of all this, I'd put the code in src/groovy and src/java, but in test-specific packages that make it easy to exclude the compiled classes from your WAR files. You can do that with a grails.war.resources closure in BuildConfig.groovy, e.g.
grails.war.resources = { stagingDir ->
println '\nDeleting test classes\n'
delete(verbose: true) {
// adjust as needed to only delete test-specific classes
fileset dir: stagingDir, includes: '**/test/**/*.class'
}
println '\nFinished deleting test classes\n'
}

Log4net cannot find configuration file when run from Visual Studio/Microsoft Test Framework

We are writing unit tests for our business layer running under .NET 4.0. The business layer is a straightforward C# class library that usually runs within SOAP and REST web services. Our application uses log4net within a separate wrapper assembly for logging. The C# code in the logging assembly has an assembly info directive that tells log4net the name of the configuration file, a la-
[assembly: log4net.Config.XmlConfigurator(ConfigFile="AcmeLogging.config", Watch=true)]
Initializing the log4net through the wrapper works fine in the web services. When we initialize it from with our unit test assembly it does not appear to see the configuration file. The configuratino file is configured through properties to be copied to the execution directory, and we do see it in the bin\debug directory. A quick console test program using the logging assembly running from within that same folder works fine. The curious thing is that the behavior problems are intermittent, and pop up on different developers' machines at different times and cannot be cured in any deterministic way.
Stepping through the wrapper assembly code, the log4netLogManager.GetLogger() call appears to return correctly, but the list of appenders returned by log.Logger.Repository.GetAppenders() is empty. Since this incorrect behavior is the same whether the file is in the Bin\Debug folder or not, we believe that it is not seeing the file.
Any clues as to what we're missing about running log4net in the Microsoft Test Framework would be greatly appreciated.
Unit tests are unique in the fact that if you need configuration files in your unit tests you need to include them as deployment items. Here is an example of how I do this within my test class:
[TestClass]
[DeploymentItem("hibernate.cfg.xml")]
public class AsyncForwardingAppenderTest
{
}
In addition to the Deployment attribute you need to Enable Deployment in your test settings. To do this go to Test->Edit Test Settings->. Then click on Deployment area on right. Click the checkbox Enable Deployment.
After doing this and running your test your config file should be located in your test results folder. TestResults\username_machine date stamp\Out. If your config file is not located in this folder it will not work. This is what the DeploymentItem attribute does. It sticks the file in this Out folder.
If you don't want to include the DeploymentItem attribute on every test class what I did was to create a base test class that all of the tests that use log4net inherit from and mark it with the DeploymentItem attribute.

Generate ibm-webservices-ext.xmi and ibm-webservices-bnd.xmi without RAD

I'm working on webservices for WebSphere and I wish to not depend anymore from the Rational Software Delipvery Platform (aka RAD) IDE.
I'm asking if someone knows if it is possible to generate the following files:
ibm-webservices-ext.xmi
ibm-webservices-bnd.xmi
webservices.xml
without having to use RAD (eg some ant script or WebSphere batch).
This is a really annoying lock-in.
I'm trying to port these webservices projects to a more controllable development process, using maven, automatic builds, and so on, but i found it quite difficult.
Has someone solved similar issues?
If anyone is still looking for help with this, we took a slightly different approach by creating the RAD and WAS 8.5 specific files at project creation time.
For my current project, we have a fairly standard project structure and naming convention so we use a Maven archetype to create our projects and include those IBM specific files, ibm-webservices-bnd.xmi in particular, in the Maven archetype.
Easiest way to do this is to take an existing project that has those necessary files, and use the create-from-project archetype from your project folder:
mvn clean archetype:create-from-project -Dinteractive=true
Use interactive mode to give the archetype a sensible archetype.artifactId (but do not change the GAV of the project):
Define value for archetype.groupId: com.name.archgroup: : com.name.common.archetype
Define value for archetype.artifactId: MyService-archetype: : service-archetype-0.8
Define value for archetype.version: 1.0-SNAPSHOT: :
Define value for groupId: com.name.archgroup: :
Define value for artifactId: MyService: :
Define value for version: 1.0-SNAPSHOT: :
Define value for package: com.name: : com.name.common.archetype
This gets you most of the way, but the IBM files do not get processed by default. The trick then is to modify the generated target files in /MyService/target/generated-sources/archetype/target/classes/archetype-resources to also modify the IBM files. Replace instances of the old project name and package name with ${rootArtifactId} and ${groupId} keeping track of which files had the incorrect values.
Then modify the /MyService/target/generated-sources/archetype/target/classes/META-INF/maven/archetype-metadata.xml to include the files you had to manually change in the filtering. For instance, under my EJB module section, *.xmi was included but not filtered. Move the include to the filtered fileset:
<fileSet filtered="true" encoding="UTF-8">
<directory>src/main/resources</directory>
<includes>
<include>**/*.xml</include>
<include>**/*.properties</include>
<include>**/*.xmi</include>
</includes>
</fileSet>
You'll need to do this for everything that you modified to include a ${rootArtifactId} or ${groupId} so that velocity processes it in the next step:
cd target\generated-sources\archetype
mvn install
This packages up your changes and places the jar into your local repository so that you can test it out before publishing to your Maven repository server.
Once your are satisfied, add your maven repositories to target/generated-sources/archetype/pom.xml and run
mvn deploy
And instruct developers to begin using the archetype to create your mavenized projects.
Note: our ibm-webservices-bnd.xmi files appear to include something like xmi:id="RouterModule_112345678901234"
We remove this value before the mvn install as it appears to be project specific.