-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add code coverage for integration tests #17
Comments
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 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 |
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.
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.
|
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 |
link this pom file has the same use case.
|
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. |
I'm closing the issue as |
ok that sounds good. |
Make cobertura take integration test data too
The text was updated successfully, but these errors were encountered: