A unit test is a piece of code which starts with known input values, then compares the output of a word with an expected output, where the expected output is defined by the word's contract.
For example, if you were developing a word for computing symbolic derivatives, your unit tests would apply the word to certain input functions, comparing the results against the correct values. While the passing of these tests would not guarantee the algorithm is correct, it would at least ensure that what used to work keeps working, in that as soon as something breaks due to a change in another part of your program, failing tests will let you know.
Unit tests for a vocabulary are placed in test files in the same directory as the vocabulary source file (see Vocabulary loader). Two possibilities are supported:
The latter is used for vocabularies with more extensive test suites.
If the test harness needs to define words, they should be placed in a vocabulary named vocab.tests where vocab is the vocab being tested.
Writing unit tests
Several words exist for writing different kinds of unit tests. The most general one asserts that a quotation outputs a specific set of values:
Assert that a quotation throws an error:
Assert that a quotation or word has a specific static stack effect (see Stack effect checking):
All of the above are used like ordinary words but are actually parsing words. This ensures that parse-time state, namely the line number, can be associated with the test in question, and reported in test failures.
Some words help the test writer using temporary files:
Running unit tests
The following words run test harness files; any test failures are collected and printed at the end:
The following word prints failures:
Test failures are reported using the Batch error reporting mechanism and are shown in the UI error list tool.
Unit test failures are instances of a class, and are stored in a global variable:
For example, if you were developing a word for computing symbolic derivatives, your unit tests would apply the word to certain input functions, comparing the results against the correct values. While the passing of these tests would not guarantee the algorithm is correct, it would at least ensure that what used to work keeps working, in that as soon as something breaks due to a change in another part of your program, failing tests will let you know.
Unit tests for a vocabulary are placed in test files in the same directory as the vocabulary source file (see Vocabulary loader). Two possibilities are supported:
| • | Tests can be placed in a file named vocab-tests.factor. |
| • | Tests can be placed in files in the tests subdirectory. |
The latter is used for vocabularies with more extensive test suites.
If the test harness needs to define words, they should be placed in a vocabulary named vocab.tests where vocab is the vocab being tested.
Writing unit tests
Several words exist for writing different kinds of unit tests. The most general one asserts that a quotation outputs a specific set of values:
unit-test
Assert that a quotation throws an error:
must-fail
must-fail-with
Assert that a quotation or word has a specific static stack effect (see Stack effect checking):
must-infer
must-infer-as
All of the above are used like ordinary words but are actually parsing words. This ensures that parse-time state, namely the line number, can be associated with the test in question, and reported in test failures.
Some words help the test writer using temporary files:
with-test-directory ( ..a quot: ( ..a -- ..b ) -- ..b )
with-test-file ( ..a quot: ( ..a path -- ..b ) -- ..b )
Running unit tests
The following words run test harness files; any test failures are collected and printed at the end:
test ( prefix -- )
test-all ( -- )
The following word prints failures:
:test-failures ( -- )
Test failures are reported using the Batch error reporting mechanism and are shown in the UI error list tool.
Unit test failures are instances of a class, and are stored in a global variable:
test-failure
test-failures