Test driven development

Test driven development

In general, when implementing new features or resolving bugs, one should first create unit tests that cover the feature and implement the feature afterwards.

This way, during development, the test can already be run to control progress.

See also: https://en.wikipedia.org/wiki/Test-driven_development

See also: https://github.com/DLR-AMR/t8code/wiki/Testing-with-GoogleTest

How to add tests before implementing the functionality

It is good practice to implement and add unit tests for a bugfix or new feature even though you are currently not working towards resolving this feature.

However, until the feature is implemented the tests will fail. How do we handle this situation?

Our strategy is as follows:

1. Implement and add the new test cases.

2. Add DISABLED_ before the name of your test or test-suite, such that it will be compiled, but not executed. See: https://google.github.io/googletest/advanced.html#temporarily-disabling-tests

Example:

TEST(DISABLED_MyTest, SimpleTest) {
  ...
}

class DISABLED_TestSuite : public ::testing::Test {
 protected:
  void SetUp() override {
    ...
  }
};

INSTANTIATE_TEST_SUITE_P (NewFeatureTests, DISABLED_TestSuite, ..., ...);

3. If it does not exist yet, create a new issue covering the bug/feature.

4. Add the link of the issue as a comment in the new tests.

/* This test covers the functionality described in Issue: [LINK] 
 * Remove `DISABLED_` from the name of the Test(suite) or use `--gtest_also_run_disabled_tests` when you start working on the issue. 
 */
TEST(DISABLED_MyTest, DisabledTest) {
  ...
}

5. In the issue add a new message/text that links to the new tests.

// Issue text here

For this issue, tests have already been implemented at [PATH/TO/TEST1] [PATH/TO/TEST2] ... .
Remember to enable the tests by removing any `DISABLED_` in the names when you start working on this issue, or to use `--gtest_also_run_disabled_tests` during execution of the test.