I recently tried to include cobertura plugin for our project. But I ran to a strange problem. Now, if I try to do this:
mvn clean package cobertura:check-integration-test
My project assembles just fine. But after deploy here is what I get as a message:
java.lang.NoClassDefFoundError:
net/sourceforge/cobertura/coveragedata/LightClassmapListener
This happens, as I understand, because cobertura alters the bytecode of my classes. So, how should I proceed with making checks and building the code? Right now I come up with the following solution for teamcity:
First step runs cobertura:
mvn clean package cobertura:check-integration-test
After that second step runs the normal assembly:
mvn clean package
This seems to work, but it seems kind of strange, that I have to run the process of packaging twice (this takes double time), just in order to make a clean build with bytecode unaffected by cobertura plugin.
If you use qualinsight-mojo-cobertura, your classes will backuped at instrumentation time, then restored at reporting time (which will in turn result in having non-instrumented classes in the generated package).
Between intrumentation and reporting you run your tests (be it UTs, ITs) as you want (unlike maven-cobertura-plugin, qualinsight-mojo-cobertura does not run tests). For more information, check the project page (especially the Maven phases the plugin is bound to by default.)
Related
In 10 minutes, I created an empty android library and an empty android application in this git repository
https://github.com/deanhiller/compositeAndroid
As seen in my last commit, I quickly convert the android application do depend on the library via gradle's awesome composite build feature (We use this feature a TON in our monorepo so loading a project loads all the libraries source code that it uses as well). Our library is shared amongst a few projects.
I cd into compositeAndroid/MyApplication and run ./gradlew build and it fails with
* What went wrong:
Could not determine the dependencies of task ':app:mergeReleaseAssets'.
> Could not resolve all task dependencies for configuration ':app:releaseRuntimeClasspath'.
> Could not resolve com.tray.android:MyLib.
Required by:
project :app
> No matching configuration of project :MyLib was found. The consumer was configured to find a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.0' but:
- None of the consumable configurations have attributes.
I am not sure how to work around this. I have a work around to publish/consume but would much prefer composite builds as it brings the source of libraries into intellij cleanly.
Why is composite builds not working? Is there something special I have to do for android projects? The above repo I setup in 10 minutes with those 2 projects(brand new).
You can always clone and play with it yourself as well. (We will actually be releasing our monorepo open-source template however it is not working to well with android just yet).
After looking into the code under MyLib folder in the repository you shared here - it seems you've opened a regular project and intend to use it as a library
Can you please follow the steps required here and test it under a new module?
Hint: your build should result with an aar file
Let me start by saying I'm new to both ReSharper and dotCover and that I'm using v10.0.2 of both.
The attached screenshot shows solution explorer in VS and the coverage tree for a set of tests.
Whenever I run coverage, it always shows the same subset of assemblies in the coverage tree. Importantly, all of the tests shown are for code in either the Services or Infrastructure assemblies, neither of which show in the coverage tree.
Clearly, the product is not doing something right or I'm not.
Why are only some of the assemblies shown in the coverage tree?
Why aren't any of the assemblies covered by the tests I'm running
shown in the coverage tree?
How do I make it work properly?
EDIT
If it makes any difference, I'm using xUnit and have the xUnit running extension installed in ReSharper and the tests themselves run just fine.
This is due to shadow copying - when enabled, dotCover expects .pdb files to be copied too, and the standard shadow copy that xunit performs doesn't do this. If you disable shadow copy in the Unit Testing options page, it'll work fine. I think the xunit runner can be updated to fix this.
The YouTrack issue that describes what's going on is here: DCVR-7976
In my case the *.pdb files where deleted by a post-build event. After changing that, coverage-analysis worked again.
This post from the support forum of jetbrains helped me
I am building phoenix application with exrm.
Good practice suggests, that I should make tests against the same binary, I'll be pushing to production.
Exrm gives me the ability to deploy phoenix on machines, that don't have Erlang or Elixir installed, which makes pulling docker images faster.
Is there a way to start mix test against binary built by exrm?
It should be noted that releases aren't a binary file. Sure they are packaged into a tarball, but that is just to ease deployment, what it contains is effectively the binary .beam files generated with MIX_ENV=prod mix compile, plus ERTS (if you are bundling it), Erlang/Elixir .beam files, and the boot scripts/config files for starting the application, etc.
So in short your code will behave identically in a release as it would when running with MIX_ENV=prod (assuming you ran MIX_ENV=prod mix release). The only practical difference is whether or not you've correctly configured your application for being packaged in a release, and testing this boils down to doing a test deployment to /tmp/<app> and booting it to make sure you didn't forget to add dependencies to applications in mix.exs.
The other element you'd need to test is if you are doing hot upgrades/downgrades with your application, in which case you need to do test deploys locally to make sure the upgrade/downgrade is applied as expected, since exrm generates default .appup files for you, which may not always do the correct thing, or everything you need them to do, in which case you need to edit them as appropriate. I do this by deploying to /tmp/<app> starting up the old version, then deploying the upgrade tarball to /tmp/<app>/releases/<new version>/<app>.tar.gz, and running /tmp/<app>/bin/<app> upgrade <version> and testing that the application was upgraded as expected, then running the downgrade command for the previous version to see if it rolls back properly. The nature of the testing varies depending on the code changes you've made, but that's the gist of it.
Hopefully that helps answer your question!
Are there any extensions to HUnit or QuickCheck that allow a continuous integration system like Bamboo to do detailed reporting of test results?
So far, my best idea is to simply trigger the tests as part of a build script, and rely on the tests to fail with a non-zero exit code. This is effective for getting attention when a test fails, but confuses build failures with test failures and requires wading through console output to determine the problem's source.
If this is the best option with current tools, my thought is to write a reporting module for HUnit that would produce output in the JUnit XML format, then point the CI tool at it as though it were reporting on a Java project. This seems somewhat hackish, though, so I'd appreciate your thoughts both on existing options and directions for new development.
The test-framework package provides tools for integrating tests using different testing paradigms, including HUnit and QuickCheck, and its console test runner can be passed a flag that makes it produce JUnit-compatible XML. We use it with Jenkins for continuous integration.
Invocation example:
$ ./test --jxml=test-results.xml
I've just released a package which generates test-suites based off modules containing quickCheck properties: http://hackage.haskell.org/package/tasty-integrate
This is one step above test-framework/tasty at the moment, as it forcefully pulls/aggregates them off the filesystem, instead of relying upon per-file record keeping. I hope this helps your CI process.
In our build process we're currently using MBUnit 2.x tests, called from an NAnt task, called from CruiseControl.NET. I've uprgaded to Gallio and MBUnit 3.x locally and am able to run tests from VS2008. I'm having trouble getting our build process upgraded. It looks like we have two options, either run the tests from CruiseControl.net or from NAnt. Based on this, I have two questions:
With all other things being equal, where should these tests be run, NAnt or CruiseControl.net, or does it really matter at all?
If you like doing this sort of thing in NAnt, do you have any documentation or examples of how to implement it? I've found documentation for the CC.NET soution in my Gallio\extra\CCNet directory in the Gallio installation.
Thanks
Your options for running tests as part of your build with Gallio are similar to what they were with MbUnit v2.
I recommend running the tests from your NAnt or MSBuild scripts using the provided tasks in Gallio.NAntTasks.dll and Gallio.MSBuildTasks.dll.
However, if you want to run the tests directly from the CCNet configuration, then you can add a CCNet task to execute the Gallio.Echo.exe program.
Here's a bit more info on the NAnt task that someone else blogged about. Some of the details have changed in recent releases but it should get you on the right track.
http://testdrivendevelopment.wordpress.com/2008/12/01/use-nant-to-run-mbunit-tests-using-gallio/