<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Testing on maxgio's notes</title><link>https://notes.maxgio.me/tags/testing/</link><description>Recent content in Testing on maxgio's notes</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 29 Aug 2026 19:52:33 +0200</lastBuildDate><atom:link href="https://notes.maxgio.me/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>The Binary I Ship Is the Binary I Want to Test</title><link>https://notes.maxgio.me/notes/the-binary-i-ship-is-the-binary-i-want-to-test/</link><pubDate>Sat, 29 Aug 2026 19:52:33 +0200</pubDate><guid>https://notes.maxgio.me/notes/the-binary-i-ship-is-the-binary-i-want-to-test/</guid><description>This article expands on my OpenSouthCode 2026 talk.
I have a slightly awkward question for anyone who collects code coverage in CI:
Are you testing the same binary that you ship?
For many projects, the honest answer is no.
Traditional coverage starts at compile time. Go builds need -cover. GCC uses --coverage, shorthand for -fprofile-arcs -ftest-coverage when compiling and -lgcov when linking. Clang&amp;rsquo;s LLVM source-based coverage uses -fprofile-instr-generate -fcoverage-mapping. llvm-profdata indexes the raw profile, and llvm-cov creates the report.</description></item></channel></rss>