Issues with Code Coverage

Some issues and possible solutions:

• Confusion of source and build directory You are typically in the source directory to make changes to the files and in the build directory to enter the build commands and run/test the program.

  Solutions:

  • Stay in the build directory and only reference the source directory when needed
  • Have a quick way to move between directories, e.g., aliases or cdargs
  • Use two terminals, one in the source directory and one in the build directory

• Difficulty entering commands Some commands have tricky, and hard-to-remember, commands. Some commands were simple, but the arguments were complicated, e.g., complicated file paths.

  Solutions:

  • Use tab-completion as much as you can, even for partial paths
  • Copy and paste long file paths or commands with long file paths
  • Use the built-in copy-to-clipboard that I often put on long or complex commands:
  • Use aliases for common commands
  • Use a text expansion tool, e.g., on macOS Typinator or TextExpander
  • Redo the commands from the beginning

• Messing everything up Someone on the team already made the needed commit, but you have it committed locally. Or, you accidentally created an in-source build with cmake.

  Solutions:

  • Abandon that environment. Kill the window with the GitHub codespace in it, and delete the codespace. Then, create another.
  • Delete the build directory. Your process should support deleting the build directory whenever needed.

• Not getting expected results You are using the commands, but they aren't working right. Perhaps a file is missing. Chances are, it did not get generated.

  Solutions:

  • Reenter the commands from the beginning.

• Not carefully reading the instructions For example, "the command line for the compile up to the first argument after the –coverage". A command line is a single line, not all of this. The entire command line for that problem is:

  And the solution is something like:

• Not realizing that software development tools give us lots of data So when looking for code coverage, the commands may give us code coverage data for many other things that we have no control over and don't care about, e.g., stl_algo.h. The ability to focus on what's important is essential.

  Solutions:

  • Read over the commands. Recognize the filenames from the code you are working on.
  • With other projects, try the same thing. See what stays the same.
  • Try to reduce what you have to view. Using grep is essential.

• Not understanding that commands do not always repeat exactly Commands can fail. Compilers can crash. There could be file system or memory errors. There can be network errors.

  Solutions:

  • Try it again. See if you get the problem repeatably.
  • Use a repeatable environment. Two installations of WSL can be set up very differently. GitHub Codespaces, especially when configured, give us a repeatable environment. Note that even they can fail.