Unit testing

Racket’s emphasis on func­tional program­ming natu­rally leads to an emphasis on unit testing. Why? Because as func­tions become self-contained—that is, they no longer rely on external state or muta­tion—they become easier to test. And when some­thing is easy to test, it’s more likely to actu­ally be tested.

Unit testing is the cate­gory of program testing that checks the behavior of indi­vidual func­tions—the epony­mous “units”. (One among many testing cate­gories.) Unit testing has two purposes:

Though unit testing is a virtuous habit, it’s always optional. If you’re program­ming in an exper­i­mental or exploratory way—meaning, inten­tion­ally making & breaking things—unit tests can be a distrac­tion.

As the design of the program firms up, unit tests become increas­ingly valu­able. They allow you to add rigor to your func­tions by nailing down expec­ta­tions. In that way, unit tests are similar to contracts. But whereas contracts make guar­an­tees about the outside inter­face of a func­tion, unit tests vali­date its inner work­ings.

For released programs, unit tests are indis­pens­able. They provide a base­line to measure the correct­ness of future revi­sions of the program. This is espe­cially impor­tant when you’re making program­ming languages: others will be writing programs with your language, and you want to mini­mize the chance that revi­sions to the language will break those programs.

Writing checks

Racket includes a library called rackunit that allows us to create unit tests called checks. Each check is an asser­tion about the behavior of the program, usually consisting of a func­tion call and the expected result. If the check is valid, it passes silently. If the check is invalid, an error is raised that tells us both the expected and actual result:

rackunit has built-in checks for the stan­dard equality func­tions, and corre­sponding negated checks:

check-true and check-false are short­hand checks for pred­i­cates:

The special check-= can test whether a numer­ical result falls within a certain toler­ance of a precise result, which is useful for inexact or prob­a­bilistic checks:

We can also check errors and excep­tions with check-exn. For this check, we need two input argu­ments. First, a pred­i­cate that describes the excep­tion we expect to get. Second, a test expres­sion that raises an excep­tion. We wrap this expres­sion in a lambda to prevent it from being imme­di­ately eval­u­ated. The check passes if the expres­sion raises an excep­tion that matches the pred­i­cate. For instance, (/ 25 0) will raise an excep­tion of type exn:fail:contract?, but (/ 25 5) will not:

Checks are easy to work with because they’re simple, flex­ible, and self-contained. Beware, however: as program code, they’re vulner­able to the same defects of mind that can afflict other parts of the code. There’s no way for rackunit to know whether your checks are complete or them­selves correct. That remains your job.

Running unit tests in DrRacket

Checks are only valu­able when they’re being run. How often? As often as possible. For that reason, other Racket tools coop­erate with the test submodule.

When you run a source file in DrRacket, it will also eval­uate any submodule in the file called test.  + Within DrRacket, you can change this default behavior through the menu item Language → Choose Language … → Submod­ules to Run. Though you can use module to make this submodule, it’s often conve­nient to use module+, which makes a submodule that auto­mat­i­cally pulls in the existing bind­ings in the file (which you need for running checks):

Further­more, a submodule made with module+ can be defined in pieces, so a source file can have tests inter­spersed with func­tion defi­n­i­tions:  + We only need to import rackunit once within the submodule.

This way, checks are close to the func­tions they test, and it’s easier to work between the two.

When the source file is run under normal circum­stances (e.g., from the command line, or imported by another module), the test submodule will not be eval­u­ated.

Running unit tests in a package

The raco pkg command-line tool can also auto­mat­i­cally run tests.

Though test submod­ules are handy, a package author always has the choice whether to put checks in test submod­ules, or create sepa­rate files strictly for testing. Racket’s package-config­u­ra­tion tools allow even more gran­ular control of which files get tested and which are omitted.

Further