{"id":983,"date":"2016-04-19T16:38:01","date_gmt":"2016-04-19T23:38:01","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=983"},"modified":"2016-04-19T16:38:01","modified_gmt":"2016-04-19T23:38:01","slug":"filling-a-gap-in-istanbul-coverage","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/filling-a-gap-in-istanbul-coverage\/","title":{"rendered":"Filling a gap in Istanbul coverage"},"content":{"rendered":"

I\u2019m at no loss for blog material, but have been short on time (that\u2019s not going to change, so I\u2019ll need to tweak priorities). But\u2026I wanted to write something a bit different  from normal in case anyone else ever needs to solve this specific problem (or if anyone else knows that this problem already has an even better solution).<\/p>\n

Our team uses a tool called Istanbul<\/a> to measure code coverage. It generates a report that looks sort of like this (minus the privacy scribbling).\"image\"<\/a>\"image\"<\/a><\/p>\n

\n

For those who don\u2019t know me, I feel compelled to once again share that I think Code Coverage is a wonderful tool, but a horrible metric. Driving coverage numbers up purely for the sake of getting a higher number is idiotic and irresponsible. However, the value of discovering untested and unreachable code is invaluable, and dismissing the tool entirely can be worse than using the measurements incorrectly.<\/p>\n<\/blockquote>\n

The Missing Piece<\/h4>\n

Istanbul shows all up coverage for our web app (about 600 files in 300 or so directories). What I wanted to do, was to break down coverage by feature team as well. The \u201celegant\u201d solution would be to create a map of files to features, then add code to the Istanbul reporter to add the feature team to each file \/ directory, and then modify the table output to include the ability to filter by team (or create separate reports by team).<\/p>\n

I don\u2019t have time for the elegant solution (but here\u2019s where someone can tell me if it already exists).<\/p>\n

The (or \u201cMy\u201d) Solution<\/h4>\n

This seems like a job for Excel, so first, I looked to see if Istanbul had CSV as a reporter format (it doesn\u2019t). It does, however output json and xml, so I figured a quick and dirty solution was possible.<\/p>\n

The first thing I did was assign a team owner to each code directory. I pulled the list of directories from the Istanbul report (I copied from the html, but I could have pulled from the xml as well), and then used excel to create a CSV file with file and owner. I could figure out a team owner for over 90% of the files from the name (thanks to reasonable naming conventions!), and I used git log to discover the rest. I ended up with a format that looked like this:<\/p>\n

app.command-foo,SomeTeam
app.components.a,SomeTeam
app.components.b,AnotherTeam
app.components.c,SomeTeam
app.components.d,SomeOtherTeam<\/font><\/code> <\/p>\n

Then it was a matter of parsing the coverage xml created by Istanbul and making a new<\/em> CSV with the data I cared about (directory, coverage percentage, statements, and statements hit). The latter two are critical, because I would need to recalculate coverage per team.<\/p>\n

There was a time (like my first 20+ years in software) where a batch file was my answer for almost anything, but lately \u2013 and especially in this case \u2013 a bit of powershell was the right tool for the job.<\/p>\n

The pseudo code was pretty much:<\/p>\n