Tests

---

Overview

Good test coverage is a priority in Higgs' development. Every effort should be made to provide comprehensive tests for regressions, spec compliance, etc. There are two types of tests for Higgs.

D Unittests

The D programming language provides special unittest functions to allow easy testing of modules. These tests are run at compile time during the make test target and are used to test low level functionality for code generation, garbage collection, the FFI, JavaScript operations, etc. If you are working on the D core of Higgs you may need to add tests in the appropriate unittest block (or to a test file loaded in a unittest block) to check for regressions, that the functionality you've added works, etc. These tests should only cover the core functionality; providing a base sanity check when Higgs in compiled to ensure further tests can run correctly.

test-runner.js

Most of the tests for Higgs are handled by test-runner.js; it is run during the make test target after the test binary is compiled. The test-runner first loads lib/test so that tests will have access to the various assert and utility functions it provides. Then it traverses the directories in source/tests (except tests/core) loading each file in lexicographic order (this is done so that the most most basic tests can be run first). The test-runner will fork before loading each test to prevent tests from interfering with each other.

When you fix a bug, add a new feature, etc you should check if an appropriate set of tests exists already and if so, add the necessary ones for your changes. If there isn't one already, create a new file for your set of tests. Ideally each file should be fairly focused in terms of what it tests.

When reporting a bug, it would be greatly appreciated if you could provide tests which demonstrate the bug so that these can be used to check for regressions after it is fixed.