6 Testing
All of the exports in this section are provided both by redex/reduction-semantics (which includes all non-GUI portions of Redex) and also exported by redex (which includes all of Redex).
(test-equal e1 e2) |
Tests to see if e1 is equal to e2.
(test--> reduction-relation e1 e2 ) |
Tests to see if the value of e1 (which should be a term), reduces to the e2s under reduction-relation.
(test-predicate p? e) |
Tests to see if the value of e matches the predicate p?.
(test-results) → void? |
Prints out how many tests passed and failed, and resets the counters so that next time this function is called, it prints the test results for the next round of tests.
It is easy to write grammars and reduction rules that are subtly wrong and typically such mistakes result in examples that just get stuck when viewed in a `traces’ window.
The best way to debug such programs is to find an expression that looks like it should reduce but doesn’t and try to find out what pattern is failing to match. To do so, use the redex-match special form, described above.
In particular, first ceck to see if the term matches the main non-terminal for your system (typically the expression or program nonterminal). If it does not, try to narrow down the expression to find which part of the term is failing to match and this will hopefully help you find the problem. If it does match, figure out which reduction rule should have matched, presumably by inspecting the term. Once you have that, extract a pattern from the left-hand side of the reduction rule and do the same procedure until you find a small example that shoudl work but doesn’t (but this time you might also try simplifying the pattern as well as simplifying the expression).