A0: Unit Testing
Due: Friday, January 16, 23:59 EST (UTC-5). See the course syllabus for late
policy.
Submission: Push the code to the main branch of your A0 GitLab repo.
Important: Pipelines triggered after the late-submission-period deadline will not
produce a grade.
TLDR (Quick Start)
Goal: Write thorough unit tests for a graph library using Check. You are given one
correct graph library that has no known bugs. Your test suite will be evaluated
against that correct graph, as well as several defective versions you do not have
access to. The overall evaluation process will be similar to what you did in your
labs 1 and 2.
Getting started:
1. Ensure Docker is running.
2. Clone your repo CIS2750W26/<yourusername>/A0 .
3. Open the folder inside the Docker container.
VS Code users: open the folder in VS Code → Reopen in Container.
4. In the container terminal, run: make setup-lib to select the correct
shared library for your architecture.
5. Write tests; compile, run, and push often.
NOTE: Be patient after the push. CI usually takes ~3–5 minutes, so you won't see
the output right away.
Assignment grade is zero if:
your tests fail to compile
you submit tests that fail on the correct variant
it is expected that some tests will fail on buggy variants
your tests do not run in CI.
Context / Purpose
This assignment introduces unit testing in C using the Check library. You will
design focused, repeatable tests that exercise a graph API. The autograder will
run your tests against the correct implementation and several buggy
implementations to measure how well your suite detects defects and explores
code paths. A0 is designed to prepare you for the main assignment sequence in
the course, and you will apply what you have learned in A0 in all the subsequent
assignments.
Learning Outcomes
Design and implement unit tests for a C library using Check.
Apply systematic testing techniques.
Use make to build and run tests reproducibly.
Learn the course tooling, Docker workflow, and CI feedback loop.
Files and Organization
Your A0 repository contains the following structure:
A0/
!"" .devcontainer/
#
$"" devcontainer.json
!"" .gitlab-ci.yml
!"" .gitignore
!"" README.md
$"" c/
!"" Makefile
!"" include/
#
$"" graph.h
!"" lib/
#
!"" libgraph-linux-amd64.so
#
$"" libgraph-linux-arm64.so
$"" tests/
!"" main.c
$"" test_graph_starter.c
Do not remove or rename any provided files or folders.
What goes where
What goes where
.devcontainer/
VS Code configuration for running inside the course’s Docker container.
You shouldn't need to change this.
.gitlab-ci.yml
This is what makes the autograder run.
README.md
You will complete this as part of the assignment.
c/Makefile
The build system for compiling and running your Check tests.
Useful targets:
make setup-lib – select the correct shared library ( .so file) for
your architecture
make test – build and run your tests
make clean – remove build artifacts
c/include/graph.h
The complete public API for the graph ADT.
All testing must use only this interface. You should read it carefully. It
contains the invariants, preconditions, and postconditions you'll need to
plan your tests. You must not modify this file in any way.
c/lib/
Precompiled shared graph library:
The correct graph implementation in two architectures. Run make
setup-lib to choose the correct one for your computer.
c/tests/
Your Check test suites go here.
Files provided:
main.c – the Check test runner.
test_graph_starter.c – a starter suite to help you with syntax.
Use it only as an example, don't add to it
Add your own test .c files in this folder; the Makefile will compile
them automatically.
Workflow:
1. Add test suites under c/tests/ and edit main.c as needed.
main.c has a forward declaration of starter_suite() , which
returns the initial sample test suite. starter_suite() is
implemented in test_graph_starter.c
As you create new files with additional test suites, you will define
additional functions that return Suite pointers.
Name your test files and suites to indicate what module and
function they are testing. e.g. test_graph_create.c
place their declarations into main.c , so you can use them in your
suite runner.
2. Run locally with make test .
3. Add, commit and push to trigger CI.
4. Autograder runs your tests against multiple .so variants and writes
results to the A0feedback branch.
Do not modify any of the .c or .h files outside the c/tests/ folder.
Doing so might cause your code to fail when evaluated against the
autograder and will result in the grade of zero.
You will not have access to the buggy graph implementations. Those will
be used only in the autograder process.
Getting Started
1. Clone your A0 repo on a machine with Docker.
2. Open the folder inside the container.
3. Run make setup-lib to create the architecture-appropriate symlink to
the shared library.
4. Study the public API in graph.h .
This header is the documentation for the expected behaviour of the
A0 graph library.
Read each function description carefully and use it to develop the
appropriate unit tests.
Refer to data structures notes for a refresher on graph concepts
and terminology as needed.
5. Use tests/ as your working directory for building your test suite.
6. Build and run tests with make test.
7. Push regularly; the CI pipeline will produce feedback in the A0feedback
branch.
branch.
8. Complete the README.
Grading
This assignment is graded in two phases, and the assignment grade is calculated
using the following scheme:
Correctness: (0–100), determined by autograder. The most recent grade is
used.
Concept Mastery: (0.0–1.0), via a short interview.
Assignment Grade = Correctness × Concept Mastery
NOTE: The interviews are not optional. If you skip the interview, your Concept
Mastery grade is automatically 0, which means your grade for the assignment will
be 0.
Correctness Grading Rubric
Your code is tested against several library variants:
correct (the reference implementation)
buggy1 to buggy9 (each with different intentional bugs)
Correct Variant (60% of total grade):
Your tests must all pass for the correct variant to earn any points here.
If all tests pass, your score is based on how many unique checkpoints
(coverage points) your code activates, out of a maximum (21).
If any test fails or your code crashes, you get 0 points for this part.
Buggy Variants (40% of total grade):
Each buggy variant is worth 10 points.
For each buggy variant:
Half the points (5) are awarded if your code detects the bug (i.e., at
least one test fails).
The other half (up to 5) is based on how many unique checkpoints
your tests activate compared your score for the correct variant. This
score and is scaled quadratically to reward higher coverage.
Your correctness score depends on how thoroughly your tests exercise the
graph implementation.
graph implementation.
Example Concept Mastery Questions
Describe the expected inputs, outputs, and edge cases for a graph API
function.
Give an example of a normal case, edge case, and negative case in your
suite.
How did you ensure your tests always give the same results with the same
inputs?
Explain how your Makefile’s test target works.
If make test works locally but CI fails, what would you investigate first?
How can you design tests to expose bugs you cannot see directly?
If you had more time, what additional tests would you write?
Submission
You must push the code to the main branch of your A0 GitLab repo. No other
submission process will be accepted.
Late submissions: see course outline for late submission policies.
Important: Pipelines triggered after the late-submission-period deadline will not
produce a grade.
Academic Integrity
This assignment is individual work and is subject to the University
Academic Misconduct Policy.
Do not share or receive test code.
Do not use AI to generate or edit tests, commit messages or
documentation.
This assignment description is provided for your personal learning in
CIS*2750. Redistribution is not permitted.