colcon / colcon-cargo

An extension for colcon-core to support Rust projects built with Cargo
http://colcon.readthedocs.io
Apache License 2.0
30 stars 20 forks source link

Generate test result from cargo test #3

Closed petrikvladimir closed 2 weeks ago

petrikvladimir commented 5 years ago

Calling colcon test should generate xml report with information about passed/failed tests. Otherwise colcon test-result --all is not able to give information about rust tests.

The only solution I found is:

Is there a nicer way how to get test-results ?

lelongg commented 5 years ago

I've never used cargo-test-junit but its unresolved issues doesn't make it look like an attractive dependency.

Is it reliable in your experience ?

Do you plan on having your output feature merged in the original repo ?

petrikvladimir commented 5 years ago

I agree that cargo-test-junit is not an attractive dependency. It seems not maintained, that's why I did not make PR.

In my opinion, the best way to solve it would be to parse cargo test output in python directly.

The goal is to capture test output in python:

$ cargo test  -q | grep "test result:"
test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

and transform it into 3 (?) xml outputs for unit, doc, and integration tests:

<?xml version='1.0'?>
<testsuites name='unit.xml' errors='0' failures='0' tests='8'>
</testsuites>

I guess that would be the minimum requirement for parsing outputs by colcon test-result. Optionally, we can also parse individual test cases from the cargo test output.

Does this solution sound good to you? I can try to implement it in python during the weekend.

lelongg commented 5 years ago

I dug a bit around cargo test output and it looks like it's still a work in progress, so any solution we come with should be considered temporary.

See these threads for reference:

I'm OK with your solution since it shouldn't add any dependency and do the job while cargo test output becomes more mature.

About the three XML outputs, I'm not aware of JUnit conventions but maybe tests results might land in a single file formatted this way:

<?xml version='1.0'?>
<testsuites name='tests' errors='0' failures='0' tests='8'>
    <testsuite name='unit' errors='0' failures='0' tests='4'></testsuite>
    <testsuite name='doc' errors='0' failures='0' tests='2'></testsuite>
    <testsuite name='integration' errors='0' failures='0' tests='2'></testsuite>
</testsuites>