Testing

Testing is super-duper important. We are building a safety critical system, which one of our friends will be driving, so we need to make sure that we check all the boxes in terms of knowing if a project works.

There are three main parts to our testing process:

Unit testing: testing small parts of our code by writing more code. Ideally, each .c file other than main should have an associated test file that tests the logic. These test files are meant to be run on x86. They’re run every time you open a pull request on GitHub.

Here’s an example of a unit test from the tests for our GPIO library. It sets up the pin, asserts that it was set up correctly, then ensures checking the state returns the value it was initially set to (notice that in the init settings the state is HIGH).

Our testing framework is Unity (not the game engine). Every test file has three parts:

A setup_test function, which is run before every test. It initializes all the libraries the tests need.
A teardown_test function, which is run after every test. Usually it’s empty, but it still has to be there.
Test functions, which is any function that starts with test_. They can use assertions like TEST_ASSERT_EQUAL to test conditions.

Hardware testing: running the project on the actual hardware. Also, creating validation projects that test specific parts of the hardware, but not necessarily implementing the logic. We call these smoke tests. More documentation can be found here: Smoke Tests .
Integration testing: Wiring a bunch of boards together and making sure they play nice. Hopefully by this stage our code is well tested and the logic is bullet proof, but there’s always something that comes up here.

When working remotely, hardware testing will occur by either asking a hardware member to flash your code and then telling you the results, or by video calling and debugging the project together.

To run tests from vagrant, you can use the command

scons test --<library/project>=... --test=... --platform=<x86/stm32f0>