I don’t think I ever mentioned that test-coverage information for QuantLib is available. It was produced by the awesome Peter Caspers (you read his blog, right?) and it can be accessed from http://quantlib.org/coverage/.
What do I think of the results? Glad you asked.
The usual disclaimer applies: coverage tells you what classes are exercised, but it doesn’t tell you whether they’re actually tested for correct behavior. Let’s continue, hoping that they are.
The coverage is not exceptional per se: the test suite covers about
65% of the code (if we remove the
ql/experimental folder from the
analysis and thus restrict it to the core library, the coverage is a
bit better: about 70%). Still, I was pleasantly surprised when I
first saw the figures; I had been expecting worse, given that we don’t
have a strict policy of requiring tests in contributions—which is
something I’m conflicted about, but let’s keep this discussion for
another time. The visualization gives the same impression: the core
folders are mostly green (90% and up) or yellow (75% to 90%), so not
bad; but there are a number of red zones that could be addressed.
A few parts of the code deserve some attention. For instance, the
ql/time folder are used throughout the whole library and
we should ensure that they’re covered properly. Results inside it are
mixed. There’s a lot of red, but most of it is because of
enumerations such as
TimeUnit whose only functionality
operator<<, i.e., text output; it’s not a big problem if that’s
not tested. On the other hand, coverage for classes such as
Schedule is not bad as such, but they’re so foundational
that I would expect them to be fully covered by tests.
ql/instruments folder is more of a mixed bag. There are a lot
of green files (even with 100% coverage) and lots of red files with
Another foundational folder is
ql/termstructures. There is a good
number of green files, but there are also a few red ones that
implement base classes for whole categories of term structures and
definitely shouldn’t be red (I’m looking at you,
are yellow ones that should be covered better, too: for instance, one
can drill down and see that end-of-year jumps in the
YieldTermStructure class are not tested, or that the same goes for
some edge cases in
IterativeBootstrap. It would probably be a good
idea to have a look into the subfolders (
volatility and so
In short: the coverage data provide a good starting point in case you want to start contributing to the library but you don’t have any particular project in mind: look for poorly-tested code and increase its coverage. You’ll make me happy when I see your pull request.
See you next time. Oh, and there are still places available for my next Introduction to QuantLib Development course: click here for more information.
Follow me on Twitter if you want to be notified of new posts, or add me to your Google+ circles, or subscribe via RSS: the buttons for that are in the footer. Also, make sure to check my Training page.