Unit Tests

How to run locally

Install act and docker:

Ubuntu

curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash
sudo apt remove docker docker-engine docker.io
sudo apt update
sudo apt -y install docker.io
sudo snap install docker

macOS

brew install act
brew install --cask docker

Create a personal access token.

Invoke the workflow:

act -W .github/workflows/unit-tests.yml -s GITHUB_TOKEN=[token]

-r, --reuse to reuse the container.

Get a bash shell in the container, if needed:

docker ps
docker exec -it <container name> /bin/bash

FAQ

1. The commands to build and run tests are in unit-tests.yml. For the queries on syntax please refer to the Workflow syntax for GitHub Actions.

2. External dependencies need to be mocked. For each external header, add one into the unit-tests.yml (preserve the original path parts, if needed). For each external declaration, add one into the mocks folder. For the queries on mocks please refer to the gMock Cookbook.

3. For the queries on how to write tests please refer to the GoogleTest User’s Guide. Common recommendations:

   • Tests should be fast.
   • Tests should be independent and repeatable.
   • If two or more tests operate on similar data, use a test fixture.
   • Fixture constructor/destructor should be preferred over SetUp()/TearDown() unless using ASSERT_xx.
   • EXPECT_* are preferred, as they allow more than one failure to be reported in a test. However, use ASSERT_* if it doesn’t make sense to continue when the assertion in question fails.
   • Having more constraints than necessary is bad. If a test over-specifies, it doesn’t leave enough freedom to the implementation. Use ON_CALL by default, and only use EXPECT_CALL when intend to verify that the call is made.

4. Before review:

   • Enable ClangFormat and make sure the tests code is formatted.
   • For the tests, the code is built with flags -Wall -Werror. Make sure the code builds without warnings.
   • At the bottom of the workflow summary page on GitHub, there is a section with artifacts. Artifacts include coverage report and valgrind log. They help to understand how much code is covered by tests and whether there are memory leaks. Make sure you check both.