Thursday, March 25, 2010

Visualizing code coverage

One recent goal of Thunderbird development has been to increase test coverage. Murali Nandigama has prepared a nice document on getting code coverage data. Running this on just the xpcshell tests for a recent build gave me this output.

So the output of LCOV (which does the post-processing) is passable. With enough clicks, I can figure out which lines are being covered and which ones aren't. But if you step back and try to look at the big picture… that's hard to do. Some directories sure seem good at code coverage: I mean, we hit both the lines of code in there. On the other hand, we seem bad at covering IMAP, only hitting around 11,000 lines of code (note the difference of scale). There's got to be a better big picture.

The answer I came up with was to use a treemap. Basically, treemaps are a good way to display two key attributes of data on the leafs of a tree at once: one is the color, the other is the size (actually, you can probably manage to squeeze three attributes of data under certain conditions if you vary color/saturation independently, but I'm not going that far here). In this case, the hierarchy is the folder hierarchy under mailnews (I'm not interested in m-c coverage) with the leaves being individual files, size being number of functions in a file, and color being the ratio of functions. The result with the same coverage data is the following graphic:

I've also taken the liberty to label the top-level directories so you can read them without having the mouseover capabilities. Immediately, you can see some interesting points about mailnews:

  • The IMAP code is the largest of the protocol code in terms of functions by a considerable amount. Local code, NNTP, and compose are all roughly equal in size by the same metric.
  • Some of the extensions (SMIME and MDN, actually) are not tested at all. Import code is also poorly tested.
  • Some of the MIME code is well tested; others aren't. In fact, it's hard to test a function in libmime without testing half the functions in that file. Perhaps we should have more encrypted messages in our tests?
  • Speaking of libmime, it's spread out across several files. In other components, functions are centralized into fewer files: specifically protocol, server, and folder. Wonder why? :-)
  • nsAbCardProperty is quite well-tested. LDAP files are not. RDF files everywhere are pretty poorly-tested.

I suppose I should also see how mozmill tests change these results. I'd also like to see how this changes over the history of hg. I can provide the source code to people on request, too.


Sms Messages said...

Such a very nice article. thanks for the information....

Anonymous said...

Does anyone have a link to the script that creates the treemap from lcov data?

Ted Mielczarek said...

That's a really nice way to visualize the data. The html lcov reports leave something to be desired currently.

jmdesp said...

About smime, I recently wrote a comment in the nss group that this code was written before nss lib started to include smime support directly, so it's using much lower level interface that necessary, and duplicating functionalities with nss, only they're seriously broken (some crypto algorithm are hard coded, they are some smart card behaviors it can't handle whereas it's correctly implemented in NSS).
The best thing to do would be to send a good part of it to the garbage can and rewrite it using the proper APIs.

Muriel Gerald said...

7 Ways He Shows His Love When He Has Nothing to Prove. You may have your own way of knowing that he loves you. But if you want to find out for sure, see this article for the signs he's in love with you.