Debugging and Testing

Testing and debugging play a crucial part in the pipeline of the software development process. While debugging fixes problems, testing assists in problem detection. But many possible flaws can be avoided if we adhere to specific guidelines throughout the implementation stage. In addition, since testing is expensive, it would be beneficial if we could use tools to automatically examine software before human testing became necessary. Furthermore, it’s crucial to consider when, how, and which software tests we should conduct.

In this chapter, we will cover the following topics:

• Understanding the root cause of an issue
• Debugging programs
• Static and dynamic analysis
• Testing, test-driven development (TDD), and behavior-driven development (BDD)

This chapter describes the analysis of a software defect, the use of the GNU Debugger (GDB) tool to debug a program, and the use of tools to automatically analyze software. The concepts of...

Technical requirements

The g++ compiler with the -std=c++2a option is used to compile the examples throughout the chapter. You can find the source files used in this chapter in the GitHub repository for this book at https://github.com/PacktPublishing/Expert-C-2nd-edition/tree/main/Chapter14.

Understanding the root cause of an issue

In medicine, a good doctor needs to understand the difference between treating the symptoms and curing the condition. For instance, prescribing medications to a patient with a broken arm will just soothe the symptoms; surgery is likely the best option to help bones to heal. Root cause analysis (RCA) is a systematic process that’s used to identify the fundamental cause of a problem. It tries to determine the root of the problem’s fundamental cause by following a predetermined sequence of procedures with the use of the appropriate tools. Thus, we may ascertain the following:

• What happened?
• How did it happen?
• Why did it happen?
• What appropriate measures should be taken to stop it from happening again or to lessen its impact?

According to RCA, an action in a particular place triggers another action in another place, and so on. We can determine the origins of the problem and how it evolved into the symptom...

Debugging programs

Debugging is the process of locating and fixing program bugs or problems. Interactive debugging, data/control flow analysis, and unit and integration testing are all examples of this. We will only cover interactive debugging in this part, which is the process of executing your source code line by line with breakpoints while displaying the values of the variables being used and corresponding memory addresses.

Tools for debugging a C/C++ program

There are several tools accessible in the C++ community, depending on your development environment. The following is a list of the most popular ones across various platforms:

• Linux/Unix:
  • GDB: A free open source command-line interface (CLI) debugger.
  • Eclipse: A free open source integrated development environment (IDE). It supports not only debugging but also compiling, profiling, and smart editing.
  • Valgrind: Another open source dynamic analysis tool; it is good for debugging memory leaks and threading bugs.
  • Affinic...

Static and dynamic analysis

In the previous sections, we learned about the RCA process and how to use GDB to debug a defect. This section will discuss how to analyze a program with and without executing it. The former is called dynamic analysis, while the latter is called static analysis.

Static analysis

Static analysis is used to evaluate the quality of a computer program without executing it. Although this can usually be accomplished through the use of automatic tools and code reviews/inspections, we will only focus on automatic tools in this section.

Automatic static code analysis tools are intended to compare a set of code to one or more sets of coding standards or guidelines. Typically, the terms static code analysis, static analysis, and source code analysis are used interchangeably. We may uncover many potential issues before the testing phases by scanning the whole code base with every conceivable code execution path. However, it has several limitations, which are...

Testing, TDD, and BDD

In the previous section, we learned about automatic static and dynamic program analysis. This section will concentrate on human-involved (test code preparation) tests, which are a subset of dynamic analysis. Unit testing, TDD, and BDD are examples.

Unit testing presumes that if we already have a single unit of code, we must develop a test driver and prepare input data to see whether the output is right. Following that, we perform integration tests to test multiple units at once, followed by acceptance tests to test the entire application. Because integration and acceptance tests are more difficult to maintain and more project-related than unit tests, covering them in this book is extremely difficult. Those of you who are interested can find out more by going to https://www.iso.org/standard/45142.html.

In contrast to unit tests, TDD believes that we should have test code and data first, develop some code and make it pass quickly, and finally refactor until...

Summary

In this chapter, we discussed testing and debugging in the context of the software development process. Testing uncovers problems, while RCA assists in discovering a problem at the macro level. However, good programming practices can help to prevent software defects in the early stages. Furthermore, the CLI debugging tool known as GDB can help us set breakpoints and execute a program line by line while printing variable values during program execution.

We also discussed automatic analysis tools and human-assisted testing processes. Static analysis evaluates a program’s performance without running it. Dynamic analysis tools, on the other hand, can detect flaws by simply running the program. Finally, we learned about the tactics for incorporating testing into a software development pipeline, including what, when, and how. When the coding is finished, unit testing focuses on testing individual components. TDD focuses more on how to write tests before developing code...

Further reading

• J. Rooney and L. Vanden Heuvel. Root Cause Analysis For Beginners. Quality Progress, July 2004, p.45-53.
• T. Kataoka, K. Furuto, and T. Matsumoto. The Analyzing Method of Root Causes for Software Problems. SEI Tech. Rev. no. 73, p. 81, 2011.
• K. A. Briski et al.. Minimizing code defects to improve software quality and lower development costs. IBM Rational Software Analyzer and IBM Rational PurifyPlus software.
• https://www.learncpp.com/cpp-programming/eight-c-programming-mistakes-the-compiler-wont-catch/
• B. Stroustrup and H. Sutter. C++ Core Guidelines. (https://isocpp.github.io/CppCoreGuidelines/)
• https://www.sourceware.org/gdb/
• https://www.fayewilliams.com/2014/02/21/debugging-for-beginners/
• https://www.perforce.com/blog/sca/what-static-analysis
• https://linux.die.net/man/1/g++
• https://www.embedded.com/static-vs-dynamic-analysis-for-secure-code-development-part-2/
• ISO/IEC/IEEE 29119-1:2013: Software and systems engineering...