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).
@dank8
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++.
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.
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?).
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.
