Closed oskopek closed 10 years ago
can you give a bit more insight into it.
Our tests are being supervised by the cobertura-maven-plugin, then the coveralls-maven-plugin uses it to send the data to Coveralls.io. The problem is, our integration tests (those running directly in the Java EE container) aren't being supervised by cobertura, therefore not seen in the coverage stats.
The aim is to make cobertura supervise integration tests too.
gotcha ill look into this.
We should continue all discussions here, so it's in one place. To continue on your line comment:
Yes, cobertura needs to be made aware of integration tests. I don't know how, haven't looked into it - not even sure if it's possible at all.
To give a bit more details, integration tests are mixed in the test directory with unit tests. You can spot an integration test by looking at the class name - it ends with "IT", as opposed to unit tests, which end in "Test". Most of the integration tests are in carcv-webapp, and are run with Arquillian on Wildfly.
As of my recent changes, carcv-core also has integration tests, although not run with Arquillian. Those changes also seem to have cause a problem with Travis I'm not able to fix yet, that's why the tests are "error"-ing. They run fine locally I think.
EDIT: I forgot to mention, integration tests are run through profiles - "it" in carcv-core, and for example "wildfly-it" in carcv-webapp (there are multiple there). If you want to run both, run mvn clean verify -Pit,wildfly-it
from the main directory.
They are also run in a completely different part of the maven lifecycle - in phase "integration-test" or "verify".
I've thought about this. Maybe it isn't such a good idea to include integration tests in the code coverage. That should probably just contain unit test coverage, as that's what it was designed to depict.
If we really need the test coverage for IT, we should probably switch to JaCoCo.
You might want to take a look at this: https://github.com/oscarrenalias/scalacheck-examples/tree/master/scalacheck-integration-junit
when i try to run the integration tests with this command; i have set it up pwildfly according to integration tests set up.
i get the error attached.
The settings are being picked up by the parent project but for some reason the integration tests are failing travis build
working on it.
I've recently done some work on integration tests. You should pull the newest changes from develop as soon as you can. If you're trying to exchange cobertura for JaCoCo, I'm not sure we need to. As I said above:
Nevertheless, you should be able to run integration tests from the newest commit onward. If you get any errors after pulling, paste the whole log somewhere and we can work from there.
EDIT: I reran the build, everything seems to be fine. Passes locally too. If it doesn't work, tell me how you set up your environment and what OS / Java version you use.
JaCoCo seems to be able do it. Since we already have cobertura picking up the unit tests. I will try to see if it can pick up.
Ok. Can you paste the whole log somewhere? (From Maven)
log this is the log message.
Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.deployment.default-server.default-host./carcv-webapp.UndertowDeploymentInfoService is missing [jboss.security.security-domain.carcv]"]}
Also, the cobertura checks fail. If you enabled them, it's quite expected -- they are set too strictly for our coverage right now.
standalone.xml; fixed the problem.
commit this should fix it. I am not sure why it fails when we have this phase enabled. At this time i am running out of ideas.
Are you sure we want to instrument in the process-classes
phase? I changed it to f.e. package
and the tests passed. I'm not sure I "fixed" it correctly - think you had a motivation for the process-classes
phase.
link this pom file has the same use case. gist of the above linkusage.
Sounds right. Last time I checked, you were just instrumenting them, right? Wouldn't that cause the tests to fail, because you aren't packaging them into the war file?
EDIT: Also, I'm not really comfortable with the thought of testing only the instrumented classes. We should test "normal" production code too.
ok. i wont follow that approach. I will keep this on hold and start with another feature; come back to this at a later point.
I agree. Keep the code & ideas, we might need that later on. One solution to running instrumented and not instrumented classes in tests on their own would be to create separate profiles, but lets leave it as is for now.
I'm closing the issue as wontfix
for now in order to get back to it eventually.
Thank you for all the work and time you've put into this!
ok that sounds good.
Make cobertura take integration test data too