Producing test harness for Guile
The above image and the name came from the popular Tape javascript library
Disclaimer:
This was written as a practice of learning Guile.
The code is messy and there are bugs.
Curently, Tape is not following the TAP specification (but it probably will in the future).
(use-modules (tape))
(describe "toBe"
(it "tests that a number is equal to four"
(let ((number4 4))
(expect (+ 2 2) (toBe number4))))
(it "tests that a string is equal to 'world'"
(expect "hello" (toBe "world"))))the following output is coloured
toBe
PASS: tests that a number is equal to four
FAIL: tests that a string is equal to 'world'
Expected: "world"
Received: "hello"
Summary:
Tests run: 2
TODO tests: 0
Skipped tests: 0
Expected tests passed: 1
Expected tests failed: 1
Unexpected tests failed: 0
Total time: 0.000071 secondsIt is not yet published anywhere.
- Import tape in your test file:
use-modules ('tape') - Run the test:
$ guile tests/my-test.scm
All tests need to be wrapped in a describe block (or in a tests block as an alias of describe).
You can also nest multiple describe blocks.
You can use:
itto define an individual test caseit-failto define an individual test case that is expected to failit-todoto define a todo test caseit-skipto define a test case that you want to be skippedtestas an alias toittest-failas an alias totest-failtest-skipas an alias totest-skiptest-todoas an alias totest-todo
The following combinations of hooks can be used in the given order, after the describe block:
- beforeAll, afterAll, beforeEach, afterEach
- beforeAll, afterAll
- beforeAll
- afterAll
- beforeEach afterEach
- beforeEach
- afterEach
- no hooks
Example:
(describe "A describe block"
(beforeEach (lambda () (display "This will run before each test.\n")))
...
)
due to pattern matching I decided not to implement all the 64 possible combinations (64 because all the possible combinations + the differences in the call order) with the hope that there is an easier solution to be found
Matchers are used to compare actual values against expected values in tests.
check the ./test.scm file, to see examples on how to use them
Here is all the supported matchers:
Checks if actual is equivalent to an expected value using test-eqv.
Checks if actual is equal to an expected value using test-equal.
Checks if a value is truthy using test-assert.
Checks if a value is falsy using test-assert.
Checks if actual is greater than an expected value using test-assert.
Checks if actual is less than an expected value using test-assert.
Checks if actual is approximately equal to an expected value within a given delta using test-approximate.
Checks if the actual string contains an expected substring using test-assert.
Checks if the actual list contains an expected element using test-assert.
Checks if the length of the actual (string or list) equals the expected length using test-eqv.
Checks if an expression throws an error during evaluation using test-error.
Note: Currently accepts a lambda that returns a throwing error.
This project is licensed under the LGPL License.
