How Much Code Are You Testing?

🧭 Where we left off Welcome back to our ongoing series on measuring test coverage for binary programs! In part 1 we used Go’s built-in -cover flag — clean and accurate, but only works if you own the source and can recompile. In part 2 we used valgrind and gdb to trace gzip without touching its source. In part 3 we explored Intel PIN, a proper dynamic binary instrumentation framework — powerful, but it came with a ~100MB proprietary C++ SDK and was limited to x86_64. ...

▶️ Intro : Let Me Be On the previous post we continued our journey with a more complex scenario, using a mix of gdb and valgrind to trace all the function execution inside a given binary. This time, hold on because we’re cranking up the complexity. We’ll dive deeper into low-level analysis and explore how to use Intel PIN, a powerful dynamic instrumentation framework for manipulating and inspecting executable code at runtime. (Photo by FURQAN KHURSHID) ...

▶️ Intro On the previous post we started our journey with a very simple scenario, and we used a nice feature of the Go programming language to get a measure of how much % of the target program our test is exercising. This time I am going to experiment a Proof of Concept about how we can obtain a test code coverage metric estimation for a normal binary program, without any recompilation. ...

☂️ Intro When your code includes a suite of unit tests, code coverage is an important metric to measure the test effectiveness and it’s rather easy to obtain; there are plenty of tools around. Image credits to: Nataliya Vaitkevich On the other hand, often we also need to do integration or E2E testing, as in our QA journey we are mostly running real world programs instead of single well-chosen functions. Let’s start with a basic use case, and prepare a simple program tailored for this purpose. ...