Package: cuvner
“A commanding view of your test-coverage”The command-line toolcuvprovided by this package gives some
useful tools to visualize your project’s coverage data. This means you
must first runcoverageagainst your project’s test-suite.Once you have a.coveragefile, you can use the commands
documented below (or just typecuvto explore the help).We utilize several quality open-source packages to achieve this:coverageby Ned BatchelderClickby Armin Ronacher / pocoopygmentsby Georg Brandl / pocooansicolorsby Giorgos Verigakisunidiffby Matias BordeseSource Code Pro: the best programming fontCode:https://github.com/meejah/cuvnerDocs:https://cuvner.readthedocs.orgBackground + TerminologyThis started out as some experiments in “whole-project coverage
visualization”, and then also grew some console tools that I find
useful when working with Python code.I have abandoned the pixel/graphical visualization ideas and
proofs-of-concepts into a branch and now this tool isjustthe
console visualizations – which are very useful when working on Python
code.As far as my setup, I am using Debian with a 256-color and unicode
capable shell using Solarized Dark color schemes. There are probably
bugs with other setups, and to a reasonable extent I’m happy to accept
pull-reqeusts fixing these. That said, a unicode-capable shell is a
must.Other Neat VisualizationsOther nice “coverage visualization” tools I’ve run across:of course,Coverage.pyitself comes with a
nice HTML visualizationemacs-coveragecodecov.io browser extensionshows coverage live
while browsing githubNotes on ToxIf you’re usingtoxto run tests (and you should, it’s great!) your
coverage files will – depending upon setup – end up in.tox/envname/.coverageor similar. So, you will either need to use--coverageto point cuv’ner at the right file, or simply move it to
the top-level of your project for ease-of-use.Pro Tip(tm)The “uncovered” lines start with a slightly different unicode
character than the “covered” lines, so if you’re trying to write tests
for uncovered things, you can do this on the “next file that has
uncovered things”:cuv src/file.py | less-p▌-j4That says (sincecuv lessopenis the “default” command) to runcuv lessopenonsrc/file.pyand then , in less, jump to the
first uncovered line and place it 4 lines below the top of the
screen. You can then hitnin less to go to the next one.This is precisely what thecuv nextcommand does.Console VisualizationsThe two main tools usable directly in the console arecuv graphandcuv lessopen(which can be tied directly intolessvia theLESSOPENenvironment variable). For determining coverage of
branches or individual commits, usecuv diff.cuv sparkcan
provide a quick overview of a project’s coverage.cuv graphThis displays all the files in your project and a histogram-like graph
of their coverage. Each character represents 8 lines of code, and uses
a group of unicode characters (0x2580 through 0x2587) to draw a little
graph. So, if those 8 lines are not covered at all, the graph will be
all red; if they’re all covered, it will be all green. If 2 out of the
8 lines are covered, there will be about 25% green and the rest red.The total size of each file can thus be easily seen (by the length of
the histogram part, which wraps to subsequent lines if needed) and an
idea of which parts are covered is given.TODO:testing on more terminal typeshow does it look when using something besides Solarized Dark?useful, beyond eye-candy?cuv lessopenThis command is intended to be used via theLESSOPENenvironment
variable, which lets you pre-process files that are opened withless. So, once set up (see the help viacuv lessopen--help)
you can simply runlesson any file in your project, and it will
get syntax-highlighted and show you the line-by-line coverage with a
leading green or red mini-verical bar and red background (for
uncovered lines).A header appears at the top showing the total coverage for this
particular file.TODO:probably the “proper” way to do this is via aPygmentsplugin or
extension of some sortoption to change whichPygmentsstyle is useddark/light background option?cuv diffYou can pipe agit diffto this and see a colorized version of the
diff in your console. I am using a library calledunidiffto read
the actual diff, which so far works quite nicely. That said, I’ve only
tried against the output of Git, like so:git diff | cuv diff | lessTODO:colors are unsatisfying, since for added lines they’re pretty much
the same as Git’s colored outputmaybe make it look more like the “real” underlying diff?
(e.g. re-create the @@ and so forth things)does it work with merge commits?cuv reportAnalyzes a diff file (similar tocuv diff) but outputs some brief
statistics instead of the whole diff. For example:$ git diff master.. | cuv report -
98.7%: 986 covered of 999 added lines (leaving 13 missing)cuv sparkThis shows a “spark-line” sort of thing in the console. It’s not very
useful for big projects (e.g. Twisted), but gives a very quick
overview of the coverage in a small amount of space. Using the same
unicode characters ascuv graph, this represents each file as a
single character, and its percentage coverage is graphed (so you only
get granularity down to about 12.5%).