CPSC 480-010 Software Engineering (SE) Fall 2023

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:

• By Thursday, Nov 9, 11:59:59 pm, create your repository (via GitHub classroom) and make one pass through the TDD workflow (red, green, refactor) with a single commit. Students who miss this deadline will have their overall score for Project 3 reduced by 10 points (one letter grade). I strongly advise that you start right away.

  After you make that one pass, wait until I provide feedback on your initial workflow by giving you a score for Exercise 40: CodeAnalysisTDD First Pass. If you don't have a score, I have not examined your first commit. If you are waiting to continue, send me an email.

• The rest of the project is due by 11:59:59 pm on Nov 16.

Project

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 order of the attributes in your output must follow the order above.
• If the value for an attribute is empty, the attribute is not displayed

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

Assignment

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 code that must be implemented is in the function formatAnalysisXML().
• Do not change or create tests for the function filenameToLanguage().
• Do not create any new functions.
• Using libraries or including files beyond those already defined is unnecessary and strictly forbidden.

Rules

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.

• If the file extension is used to determine the language, and there is no mapping for that language, output the error message “Extension not supported”
• When the input is from standard input, and a language cannot be determined, output the error message “Using stdin requires a declared language”

Workflow

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:

• Output of a particular attribute should occur only once in the code.
• Ideally, each rule implementation should only require one additional if-statement.
• Prefer simple conditions over complex conditions.
• Prefer initialization and if-then over if-then-else.
• Separate the logic of calculating an attribute value from the output of the attribute value.
• Initialize variables on declaration instead of declaring and then initializing.
• Prefer std::string_view to std::string.
• Instead of comparing strings to "", use the empty() method.

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.

Grading

Your score will depend on the following:

• Following the TDD process. This must be reflected in your commit history, both when commits are made and the commit messages.
• Successful implementation of the rules.
• Following the commit message guidelines.
• Coding style, including use of if-statements. The function logic should be as simple as possible. Pay attention to the coding style criteria given in class.