https://www.fabienruffin.com/https://www.fabienruffin.com/favicon.pngFabien Ruffinhttps://www.fabienruffin.com/Ghost 2.31Sun, 15 Sep 2019 09:38:43 GMT60A bit over a year ago I started revamping our build pipeline at work and moved from a 100% MSBuild process to mostly psake. We run everything from a single psake script, including cleanup, build, packaging, unit tests, unit test coverage and report generation. The main goal with this process]]>https://www.fabienruffin.com/integrating-opencover-test-coverage-statistics-with-teamcity/5ae3249a81e3d4002249a317Tue, 09 Jun 2015 13:23:00 GMT

A bit over a year ago I started revamping our build pipeline at work and moved from a 100% MSBuild process to mostly psake. We run everything from a single psake script, including cleanup, build, packaging, unit tests, unit test coverage and report generation. The main goal with this process was to produce a completely self-contained build process so that any developer in the team could just run the full build as it would run on the build server. This is great and it helps a lot when trying to troubleshoot a build issue. However, one of the drawback is that we can't use any of our build server's integrations to run our tests and test coverage and import the results. The main reason I really wanted this integration to work is that we could then fail builds when the test coverage drops. It would also make the coverage report more readily accessible for the team to look at when needed (they were previously only included as one of our build artifacts, meaning they would mostly get ignored)

We recently moved to TeamCity and importing our NUnit test results to the system was quite easy thanks to the XML report processing feature.
However, there still doesn't seem to be an easy way to import our test coverage statistics from the OpenCover reports. OpenCover is great but the tooling support for it still leaves much to be improved. Well, that was until I found out almost by accident that it is possible to import these statistics into a build results by simple writing messages into the logs. This mechanism is called "service messages" and is available in the TeamCity online documentation.

So now I need to edit my psake script to somehow parse the results. There are a few options here, and I initially tried to parse the OpenCover XML reports. This wasn't really fun though as most of the values I needed were not readily available in the report and needed to be calculated by parsing the entire report and calculating them.
Then I realised that all I wanted was just there in front of me. Looking at my build logs, here is what I found:

It turns out OpenCover is already writing out a summary to the logs, which contains all the information I needed. So I decided to take advantage of that and parse the output instead of parsing the coverage report. So back in my psake script, I am now storing the stdout from OpenCover in a variable (using | Out-String) instead of letting it write to the host directly:

I have been thinking of starting a technical blog for quite some time now. In fact, I have tried a few times over the years but it never lasted for more than a few weeks.
So why is this time going to be different, you say?

I pretty much attribute my previous failures to just a few reasons:

Keeping a blog alive takes time. A lot of time. And when you have a full time job and commitments outside of work it is not always easy to find the time to write. This time I am trying to optimise my commute time and to be productive in the 90 minutes or so I spend on the train each day. In fact this first post has been written this morning on the way to work.

"I don't have anything interesting to share" can't be an excuse anymore. Yes, it can be intimidating when you see the technology "superstars" post new articles every few days with very inspiring topics. It is easy to think that those guys are simply too good and there is just no way people would find your articles interesting. The thing is, everyone has their own experience and this is what makes YOUR blog interesting. The experience of writing a technical blog is actually something I am planning to go back to in a few years if all goes well.

English is hard... and when it is not your first language, writing a tech blog in English is a bit of a daunting task. It's not impossible, it's just that writing every article is going to take a bit longer. I have used this as an excuse for a while, but now I see it as an opportunity to improve. "Practice makes perfect", they say.

But above all, the main reason I am starting over again, is that I feel more and more that I need to give back to the tech community, even if my contributions end up being used or even just seen by a few people. So a few months ago, I finally started contributing to open source projects, as opposed to just using them (I wanted to do that for years, but finally decided to "just do it"). I've also been involved in tech meet-ups, this time as a speaker as opposed to just listening in. And the experience has been very positive so far. Feedback at meet-ups has been pretty good too, so I am now considering taking the next step and applying for conference talks. It's a lot of work, but very rewarding.

What comes as a by-product of your community engagement is that you finally have proof to back the facts you are stating in your resume/CV. When you say you have 10 years experience in a specific field, chances are you are going to have blog posts about it. Maybe you even talked about it at meet-ups and you can link back to that. Anyway, as someone who spends a lot of time in interview rooms, I can tell you that we would always hire the person who can prove he/she is passionate about his/her work rather than the one who is just saying it. Yes it is a bit unfair, but at the same time, if you do all this extra work, you eventually get rewarded.

So here we go, this is a new start. I hope you will enjoy coming back to this blog from time to time. And while you wait for the next post, start building your own online identity NOW if you haven't done so yet ;)