As an experiment, I decided to see how hard it would be to build fossil
instrumented for code coverage and run the full test suite. Turns out it
wasn't that hard to do, although it did require both configure and make
to be invoked with special conditions.
The result also ran a lot slower, but that isn't really a surprise.
The surprise to me is that the test cases in json.test achieve 83%
coverage of code in [cj]son*.c. That is much higher than I expected from
just running down the document and trying to do one of each thing listed
that can be done without much concern for edge cases or provoking errors.
After running for 8 hours, the full test suite completed, and it
measures about 38% coverage over the whole source kit. That figure did
include sqlite3.c (at just over 40% itself, but also fully half of the
executable lines of code) which we know is well covered by its own test
suite. I had also built with miniz, which was 64% covered, but I don't
know what formal testing it has externally.
I plan to stare at the result of that for a bit, and will report back
with a list of areas where it seems like we could (and likely should)
improve coverage from the regression test suite.
I'd be happy to share a zip of *.gcno, *.gcda, and *.gcov if anyone is
interested in the raw data.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
