Test coverage in QuantLib
Welcome back.
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
classes in 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 Weekday
or TimeUnit
whose only functionality
is 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 Date
,
Period
or Schedule
is not bad as such, but they’re so foundational
that I would expect them to be fully covered by tests.
The 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
sub-par coverage.
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,
defaulttermstructure.cpp
and inflationtermstructure.cpp
). There
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 (yield
, volatility
and so
on).
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.