---
title: "Discussion on \"I Built C++ Test Impact Analysis With Zero Runtime Dependencies\" | Hashnode"
description: "Discussion on \"I Built C++ Test Impact Analysis With Zero Runtime Dependencies\". How I built diff2test, a zero-dependency C++ test impact analysis tool that maps code changes to affected tests using build metadata."
url: "https://hashnode.com/posts/i-built-cpp-test-impact-analysis-with-zero-runtime-dependencies/6a94085893652adbf12cf922"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [I Built C++ Test Impact Analysis With Zero Runtime Dependencies](https://thunder-khan.hashnode.dev/i-built-cpp-test-impact-analysis-with-zero-runtime-dependencies?utm_source=hashnode&utm_medium=feed)

How I built diff2test, a zero-dependency C++ test impact analysis tool that maps code changes to affected tests using build metadata.

Aug 30 · 16 min read · thunder-khan.hashnode.dev  
Read the article

-   [#cpp](https://hashnode.com/tag/cpp)
-   [#hackathon](https://hashnode.com/tag/hackathon)
-   [#opensource](https://hashnode.com/tag/opensource)
-   [#open-source-community](https://hashnode.com/tag/open-source-community)
-   [#developer-tools](https://hashnode.com/tag/developer-tools)
-   [#testing](https://hashnode.com/tag/testing)
-   [#systems-programming](https://hashnode.com/tag/systems-programming)
-   [#software-development](https://hashnode.com/tag/software-development)

## Written by

[Ayan Khan](https://hashnode.com/@thunderkhan)

@thunderkhan · Gorakhpur, India

  
[View profile](https://hashnode.com/@thunderkhan)

Building systems, breaking abstractions, and writing about what I learn.

I’m Ayan Khan, a student software developer interested in systems programming, developer tools, open source, and applied AI. I enjoy building things from the ground up, especially projects that force me to understand what is happening beneath the abstraction layer. Most of my work revolves around C++, Python, systems-oriented software, experimentation, and learning by building. I use this blog to document the interesting parts: design decisions, mistakes, debugging stories, technical deep dives, hackathon projects, open-source work, and lessons that are worth remembering. I’m still learning, so I don’t want this to be a collection of polished “expert takes.” Think of it more as a public engineering notebook: build something, understand it properly, then write down what I learned.

## Responses

Markdown supported · ⌘↵ to post

No responses yet.