CPSC 480-010 Software Engineering (SE) Fall 2023

Project 3: Code Analysis TDD

Follow a TDD process to implement the project below. An invitation link to create the GitHub Classroom repository is on the Brightspace course page.

Due Dates:


The input for a source-code static analysis tool can come from multiple sources, including solitary files (e.g., main.cpp), directories of source-code files (e.g., src/), source-code archives (e.g., project.tar.gz, file.zip), and standard input (i.e., stdin, e.g., std::cin). In addition, solitary files and source-code archives can include a URL, e.g., https://mlcollard.net/fragment.cpp

To perform the code analysis, the source code is wrapped in a single XML element with metadata about the source code, including filename, programming language, url, hash, and LOC (lines of code). For the source code:

the resulting XML is:

Note: You may need to scroll the above to see all the attributes.

The attribute hash is of the source and is a SHA1 160-bit (20 bytes) represented in 40 hex characters, i.e., what Git uses. The xmlns:code="http://mlcollard.net/code" is not an attribute, but an XML namespace declaration, handled automatically by XMLWrapper.

The general attribute rules are:

The variety of input sources and program options for the metadata follows the Rules stated below.


Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, and implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, then commit with an appropriate commit message.

All commits must result in a program that compiles and passes all tests. This means you must successfully compile and pass the test program before committing. Any commit that does not build will result in a 0 for that step, and every commit will be checked.


The following rules are unordered. Do not refer to them by number.

Error Handling

All error messages are written to standard error (i.e., std::cerr), on their own output line, and the function should return an empty string.


The workflow for implementing one rule:

  1. Add a single new test case for a single specific rule in the test program CodeAnalysisTest.cpp
  2. Successfully compile and build
  3. Run the test program and verify that the test case fails
  4. Add the implementation only for the new test case in the file CodeAnalysis.cpp
  5. Successfully compile and build
  6. Run the test program and verify that all tests pass, including the new test case
  7. Refactor the test and the added code
  8. Successfully compile and build
  9. Run the test program and verify that all tests still pass, including the new test case
  10. Commit with the appropriate commit message

Refactoring Guidelines

All implementation should result in code that is as clean and clear as possible. For this case:

Evaluation Environment

The project is built and graded in a Docker container running Ubuntu 22.04 using the GCC compiler. This is the default for GitHub Codespaces and WSL.

On macOS, clang is the default compiler and the one you want to use in most cases. This should not cause a problem with this program. However, before you commit, I recommend ensuring your code can build and pass the tests with GCC and the default compiler clang.

Add GCC via homebrew brew install gcc.

The preset macos-gcc (in the file CMakePresets.json) provides settings to compile with GCC:

cmake .. --preset macos-gcc

To return to using clang:

cmake .. --fresh

Instead of flipping back and forth in the same build directory, use two build directories, one for clang and one for GCC. Be sure to build and test in both build directories before you commit.


Your score will depend on the following: