Specifications

Specifications are the contexts within which tests are defined. Any logical unit of behavior or functionality will fit well within a single specification. If you decide further on in your development cycle that the Specifications are too broad or too precise, split them up and reassemble them as you please. Don’t sweat it too much: while the name is important for you and your understanding of the tests and code, the framework doesn’t really care.

desc

The keyword that is used for test descriptions is desc. It is a function taking two arguments: a descriptive name as a string and a function that will contain Expectations.

You’ll notice that this conflicts with the standard descending order keyword. This name was chosen because it is not anticipated that the keyword would be used directly from the default namespace. Usually, you should use it from its home context .tst, as in .tst.desc.

.tst.desc["Some thing"]{
 ...
 }

The practical upshot of this is that any references will always properly resolve regardless of the context they are in:

\l .foo
.tst.desc["Some thing"]{
 ...
 }

You may have noticed that liberal use of partial application is used in examples. While this is not necessary, it lends the code a sort of a “DSL” feel that the author finds appealing and easy to read. This convention is used elsewhere and I recommend it.