©
C
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:
$FIXTURES/
All of your uploaded fixtures will be here.
$STUDENT/
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
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.
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.Create a Run Program test.
- 2.Enter the compilation command to compile the code:
- 1.
gcc -o example -g example.c
or similar. You can also run yourmake
file, if you have uploaded this to the$FIXTURES
folder. Or use another compiler if you prefer.
IO Tests are great for console based programs and allow you to give an input to it and specify an expected output.
- 1.In Program to Test, execute the compiled student code, just like you would do in your own terminal: e.g.
./example
. - 2.Give a name, so students know what the test is about.
- 3.Specify input and expected output. Several options are available to match a wider range of outputs.
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):money.h
#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 */
money.c
#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) {
free(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");
money_free(m);
} END_TEST
â
â
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_set_cg_junit_xml(runner);
srunner_run_all(runner, CK_NORMAL);
no_failed = srunner_ntests_failed(runner);
srunner_free(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
- 1.Upload the unit test file and Makefile as a $FIXTURE in the CodeGrade setup.
- 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.In the category where you want the test to live first create a Run Program Test with the build command:
make
. - 4.Create a Unit Test
- 5.Select Check.
- 6.As the extra arguments write:
test_money

Compiling C code and running unit tests using the Check framework in CodeGrade.
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.
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.
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.
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.
rules:
- id: if-statement
match-expected: true
pattern: |
if ($COND) {
...
}
message: You must use an if-statement in your code!
severity: INFO
languages:
- 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.
- 1.Upload the YAML (.yml) with your Code Structure tests in it as a $FIXTURE in the CodeGrade setup.
- 2.In the category where you want the test to live create a Unit Test.
- 3.Select semgrep.
- 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:

Valgrind is a tool that can help detect memory leaks, see https://valgrind.org/ 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.Create a new Run Program Step.
- 2.Write the command:
valgrind --leak-check=yes --error-exitcode=1 -q ./example
. Replace./example
with your student's executable. - 3.This will now pass if no memory leaks were found and fail otherwise!
- 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.
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!
Last modified 5mo ago