|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [MirageOS-devel] code coverage testing with Bisect
Hi, I've been having a lot of fun with bisect[1] recently-- I've been using it to see which parts of the mirage-block-volume[2] and shared-block-ring[3] libraries are completely untouched by their unit tests. I found the following game to be quite addictive: 1. "make coverage", and load result in web-browser 2. spot a big chunk of obvious red (danger, danger, danger) 3. (thinking carefully about what could go wrong) devise an interesting test to stress the red bits (obviously you could cover it with a 'noddy' test but there is probably no point) 4. "make coverage", reload in browser and see the red go green! I've hooked it up with coveralls.io (admittedly in a bit of a hacky way[4]) such that the master branch is firmly in "development" mode, linking against bisect, and without checking in the oasis autogen rubbish. The .travis.yml runs both the travisci-skeleton script and then invokes ocveralls[5] to upload the results. I've added a separate "make release" step which removes bisect and checks in the autogen (presumably into a release branch). Perhaps eventually this could make a github pull request (with the "hub" tool?) and make an opam package? I think the game is made even more addictive when the coveralls badge changes colour, see: Here's an example bisect report (the code is a work-in-progress): If you haven't given bisect a go -- I recommend playing with it. Also, if you can think of a nicer way to integrate this -- I admit using 'sed' on the _oasis file is a bit of a hack -- please let me know! Cheers, Dave _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |