Unit testing General-Purpose languages like C++ (Techniques and methods)

I’m looking for some good resoruces where I can educate myself about techniques and methods of testing machine languages such as C++ (coded closer to the software / hardware interface). I’m wanting to discover runtime tests that try to expose program memory leaks, fatal errors, exploits, memory overflows and such, not so much how to program in C++ (is there a difference?).

Backstory: I am applying for a job that uses Test-Driven Development and discusses almost working in a pair with one tester and one developer to write and test the program together simultaneously (i dont quite see how this would work, but trying put my self in their shoes to understand their perspective).


Glad to hear about your interest!
For fundamental Techniques in testing languages like C++, consider exploring resources for foundational knowledge.

Websites like -

delve into testing methodologies.

TDD- By Example by Kent Beck is also an excellent read.
Don’t forget to check out online platforms like HackerRank & LeetCode for hands-on coding challenges in C++.

Best of Luck with your learning journey!!


Hi, welcome to the MOT Community Daniel.

Before we start, can you give us some context, how did you find out about the ministry of test forum? As in like what made you ask this question here instead on on SO or someplace else?

I mainly want to gently build some framing to your question and not answer it, because @ansha_batra has pretty well done that already. But I want to “frame”, so that other visitors can also learn some of the software history behind types of languages. C++ is, as you state a “machine language”, but it’s not a general purpose language. Moreover the things we are really looking for when we talk about unit testing strategies are less about what the language get’s used for, and more about whether the language nature. Whether the language is strongly typed or not, and whether it is pre-compiled or interpreted as well as whether it incorporates things like garbage collection are the main things that impact unit testing tooling.
That said, learning to unit test ‘machine’ languages like C/C++ puts you in a good place to know how to test all of the other kinds, but not because they stem from the foundation languages. But they are still a good and well documented starting place.


Thanks Ansha, these are awsome!


Hi Conrad, (thanks for being gentle and for your thoughtful response its spot on for what im trying to learn)

Im a Software Tester who started out as a Bookkeeper / Clerk and had too much fun finding bugs in a new Meter Data to Billing integration, my testers curiousity lept from there. I’ve watched MOT from the sidelines on and off for 20 yrs.

I have updated the OP hopefully its clearer now.

I’m wanting to discover runtime tests that try to expose program memory leaks, fatal errors, exploits, memory overflows and such, not so much how to program in C++ (is there a difference?).

Hence not posting it to Stack Exchange communities, where i go by User dank8 - Stack Overflow

1 Like

Once again welcome to the club, yes it is a great journey for us always learning. Bookkeeping is a ‘details’ pursuit, so it’s not surprising that software creation and the process of injecting quality and order into software are an alignment of interests.

Most testers today are testing apps written in “modern” programming languages where leaks and overflows still happen but come from different places. I have been doing software for so long now that I find I jump into great detail quite quickly, so do stop me anywhere. My first job as QA came off of a background in coding C/C++ of ~14 years, so jumping from coder to full-time unit testing and integration testing was my first QA role. A basic understanding of C/C++ application architecture is going to help you a lot. I had the advantage in that first QA job of the experience as a coder, but I was mostly using off the shelf tools. Static-analysis, runtime analysis and stressing tools, I hardly ever looked at the code itself.

So. Because C++ has no ‘memory management’ and garbage collection built in and is designed to function on constrained-resource hardware platforms, it’s actually more a bloat-free app framework if you like. It’s also strict and stable in ways that modern languages are not. Additionally C/C++ and embedded systems tend to have “resource use” as a major constraint. How they measure performance is also far more objective, all of which helps us because measuring tools are more prolific in any objective world where the hardware constraints are higher value.

  • It’s also a ‘standardised’ language, so the first tool you have really is the compiler. Inspecting compile-time warnings is vanilla in most languages, any modules with a high warning count, are areas ripe with bugs. That’s the static analysis part of finding bugs “in code”. A load of off the shelf expensive tools are available to supplement the compiler warnings as a tool, these tools are often sold as security tools. And many of these tools will also offer to inspect compiled binaries. Static analysis is a bit boring, but is vital
  • Memory leaks come from so many different places, but it’s typical to “drop the ceiling” using tools that limit a process RAM usage. Doing resource leak over time testing also requires comparing ram usage of previous versions on the app for as far back as a year ago even under the same load condition for variation. Tools that let you probe memory usage add to this mix of memory stressing. Remember you don’t have to find the actual “leak”, you just need to identify roughly what activity causes the most water loss.
  • Security, is 2 sided. A load of static analysis tools, so many and varied cover 2 angles of security, penetration and secure coding practise. But you will need to learn a bit about how apps leak secrets and how ‘secure coding’ to prevent buffer overflows for example works, very little beats online hacking tutorials, google for ‘try hack me’ to get started.
  • Stress : Beyond just memory stress, stressing the application by constraining or limiting CPU cycles, storage and network as well as any other external I/O can be done using many existing tools. Monitoring which resource the system uses the most of, but mostly being able to very closely observe how the app behaves under stress helps you find bug areas. The “observing” is often done by “instrumenting” the system under test, which is a coding and re-compiling exercise.

I’m sure you know a fair bit about these test techniques already, and I hope that it’s also more helpful to you, to think of them and others as largely separate specialised activities. All I’ve done is give a cheat sheet, but hope it helps fill out the stage a bit.

1 Like

thanks this is the ‘start of the trail’ i was looking for :slight_smile:

1 Like