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/.

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.