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.
5 comments:
Such a very nice article. thanks for the information....
Does anyone have a link to the script that creates the treemap from lcov data?
That's a really nice way to visualize the data. The html lcov reports leave something to be desired currently.
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.
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.
Post a Comment