Step 1: Setup

CodeGrade AutoTest runs on Ubuntu (18.04.2 LTS) machines which you can configure in any way that you want.
In the setup section of your AutoTest, you can upload any files you might need for testing. For instance C library files, or unit testing scripts. These files are called Fixtures and will be placed in the $FIXTURES directory on the Virtual Server.
The file structure of the server is like this:
All of your uploaded fixtures will be here.
This is where the submission of student is placed.
Tests are executed from this directory.
After uploading any files you might need, you can run some setup to install any packages you might need.
  • Global setup script: this is where you install any additional packages you want to be available on the server, using sudo apt install <package>. The global setup only runs once and is then cached, so the student submission won't be available here yet.
  • Per-student setup script: this will run once when running the autograding for a student and will run before all tests. This is a good place to move $FIXTURES to the $STUDENT directory in case the student solution needs some input files to run correctly or if you are doing unit testing, as the unit tests have to be placed in the same directory as the student files. Move all fixtures with the following command: cp $FIXTURES/* $STUDENT
Use any command in the Global Setup Script field to install software or run your setup script

Step 2: Create your tests

Now that you have created the setup, it's time to create the actual tests. Do this by pressing the "Add Level" button and then the "Add Category" button.
All tests in AutoTest fill in a specific rubric category that you select. After selecting the category, you can start creating tests that will fill it in. Multiple test types are available in CodeGrade, which can be used together depending on your needs and wishes.

Compile the student's code

The first step in running any tests is compiling the code, that will give us an executable that we can use in subsequent tests.
Compiling student code in one step, and executing the code in the next step.
  1. 1.
    Create a Run Program test.
  2. 2.
    Enter the compilation command to compile the code:
    1. 1.
      gcc -o example -g example.c or similar. You can also run your make file, if you have uploaded this to the $FIXTURES folder. Or use another compiler if you prefer.

Set up an IO Test

IO Tests are great for console based programs and allow you to give an input to it and specify an expected output.
  1. 1.
    In Program to Test, execute the compiled student code, just like you would do in your own terminal: e.g. ./example.
  2. 2.
    Give a name, so students know what the test is about.
  3. 3.
    Specify input and expected output. Several options are available to match a wider range of outputs.

Set up a Check unit test

Upload a Check unit test file and your Makefile as a $FIXTURE and automatically run unit tests on the code.
Imagine students have to code a very simple program that represents money, in money.h and money.c (taken from the Check tutorial):
#ifndef MONEY_H
#define MONEY_H
typedef struct Money Money;
Money *create_money(int amount, char *currenty);
int money_amount(Money *m);
char *money_currency(Money *m);
void money_free(Money *m);
#endif /* MONEY_H */
#include <stdlib.h>
#include "money.h"
struct Money {
int amount;
char *currency;
Money *money_create(int amount, char* currency) {
Money *m = malloc(sizeof(Money));
if (m == NULL) {
return NULL;
m->amount = amount;
m->currency = currency;
return m;
int money_amount(Money* m) {
return m->amount;
char *money_currency(Money* m) {
return m->currency;
void money_free(Money* m) {
A powerful way to test the individual methods, is to write unit tests. In this example, we can test the student's code with the following unit tests in a file called test_money.c. Make sure to also include #include <cg-check.h> in your code, to make it compatible with CodeGrade. Also, you will have to add the line srunner_set_cg_junit_xml(runner); in the main function to set the output file correctly for CodeGrade.
#include <check.h>
#include <cg-check.h>
#include "money.h"
#include <stdlib.h>
START_TEST(test_money_create) {
Money *m;
extern Money *money_create(int, char*);
m = money_create(5, "USD");
ck_assert_int_eq(money_amount(m), 5);
ck_assert_str_eq(money_currency(m), "USD");
Suite *money_suite(void) {
Suite *s;
TCase *tc_core;
s = suite_create("Money");
tc_core = tcase_create("Core");
tcase_add_test(tc_core, test_money_create);
suite_add_tcase(s, tc_core);
return s;
int main(void) {
int no_failed = 0;
Suite *s;
SRunner *runner;
s = money_suite();
runner = srunner_create(s);
srunner_run_all(runner, CK_NORMAL);
no_failed = srunner_ntests_failed(runner);
return (no_failed == 0) ? EXIT_SUCCESS : EXIT_FAILURE;
Now that you have the student's code and your unit test files, you can build these using a Makefile. See for instance this example:
CC = gcc
CFLAGS = -std=c11 -O2 -Wall -Werror -D_GNU_SOURCE
all: test_money
test_money: CFLAGS += $(shell pkg-config --cflags check)
test_money: LDLIBS += $(shell pkg-config --libs check)
test_money: money.o

Creating the unit test in CodeGrade

  1. 1.
    Upload the unit test file and Makefile as a $FIXTURE in the CodeGrade setup.
  2. 2.
    Copy the unit test file and Makefile to the student directory in the per-student setup script using: cp $FIXTURES/test_money.c $STUDENT && cp $FIXTURES/Makefile $STUDENT.
  3. 3.
    In the category where you want the test to live first create a Run Program Test with the build command: make.
  4. 4.
    Create a Unit Test
  5. 5.
    Select Check.
  6. 6.
    As the extra arguments write: test_money
Compiling C code and running unit tests using the Check framework in CodeGrade.

Set up a Clang-tidy Code Quality test

Automatically run static code analysis on the student's code. In C you can do that with Clang-tidy.
​Clang-tidy is a static code analysis tool for C and C++ that is built-in to CodeGrade. It is a traditional linter: it checks for typical programming errors in the code.
Amongst other things, Clang-tidy can detect:
  • Style violations;
  • Interface misuse;
  • Common bugs that can be detected statically.

Create Code Quality test

After choosing the Code Quality test in your AutoTest category, you can simply select a linter from the dropdown list. Choose Clang-tidy for your C assignment.
After doing so, you must select extra arguments to select the checks and the file to check. Commonly a good argument to start with is --checks='*' money.c to enable all checks and select the file you want to check (replace money.c with your filename). Feel free to explore the other checks and options that are available for Clang-tidy.
Running a Code Quality test (linter) for your C assignment.

Set up a Code Structure test

CodeGrade integrates a tool called Semgrep to make it easy to perform more complex code analysis by allowing you to write rules in a human readable format. You can provide generic or language specific patterns, which are then found in the code. With its pattern syntax, you can find:
  • Equivalences: Matching code that means the same thing even though it looks different.
  • Wildcards / ellipsis (...): Matching any statement, expression or variable.
  • Metavariables ($X): Matching unknown expressions that you do not yet know what they will exactly look like, but want to be the same variable in multiple parts of your pattern.

Writing the tests

Semgrep is pre-installed in the Unit Test. You will write your Semgrep Code Structure tests in a YAML file and upload this as a fixture in the setup section of AutoTest. Semgrep has an online editor that can be used to check and create your patterns:
For instance, this is a ruleset to detect if a student uses an if-statement or not in their code.
- id: if-statement
match-expected: true
pattern: |
if ($COND) {
message: You must use an if-statement in your code!
severity: INFO
- c
We use the ellipses (the … in the pattern) here, so that any code can be inside the blocks of the if-statement. The $COND captures any variable / condition. Save this in a file named for instance rules.yml.
  • Patterns
    • The ellipsis (...) is used to capture anything
    • metavariables $EL (element) and $LST (list) capture the two parts of the for-loop declaration (the naming of these metavariables is irrelevant and could have been anything else).
    • The same is done for the while loop condition $COND
  • Messages We are able to provide understandable messages that are parsed by the wrapper script making our tests understandable for our students.
  • Match-expected Importantly, we have added the match-expected field (this is added in the CodeGrade wrapper script and cannot be tested in regular semgrep), with putting this field to True for the for-loop rule, we specify that we are expecting a match in order to pass that test.
  • Severity This dictates the level of severity of failing the rule. The penalty for each severity level can be set in the Unit Test step.
  • languages Here we specify the language of the scripts which semgrep will be checking.

Creating the test in CodeGrade

  1. 1.
    Upload the YAML (.yml) with your Code Structure tests in it as a $FIXTURE in the CodeGrade setup.
  2. 2.
    In the category where you want the test to live create a Unit Test.
  3. 3.
    Select semgrep.
  4. 4.
    Give the follow extra argument: $FIXTURES/your-test-file.yml $STUDENT.
If you run this on your student's code, it will then show up like this:

Set up a memory leak check (Valgrind)

Valgrind is a tool that can help detect memory leaks, see for more info. Valgrind is automatically installed on CodeGrade and can be used in a Run Program Test step to check for memory leaks:
  1. 1.
    Create a new Run Program Step.
  2. 2.
    Write the command: valgrind --leak-check=yes --error-exitcode=1 -q ./example. Replace ./example with your student's executable.
  3. 3.
    This will now pass if no memory leaks were found and fail otherwise!

Other test types

  • Capture Points Tests: Use your own custom grading script, upload it as a $FIXTURE, execute it in this test and make sure it outputs a float between 0.0 and 1.0, this score will then be the number of points a student receives.
  • Checkpoints: Only execute tests below the checkpoint if the tests above the checkpoint reach a certain score. Great for separating simple and advanced tests.

Step 3: Start the AutoTest

Once you have created a configuration, press start and your AutoTest will start running. In the General Settings, you should have already uploaded a Test Submission, so you will see the results of this straight away.
Once it's started and your assignment is set to Open or Done, students can hand in and get immediate feedback!