Three advantages of `test` submodules interspersed with the
implementation code:
* You're usually working on implementation and tests at the same time,
and putting them adjacent in the same file is helpful (without fancy IDE
support).
* These tests constitute documentation for someone who has to maintain
the code later, so, while they're looking at the code to understand it,
they can also be looking at the tests, to speed along their understanding.
* When the tests are in with the code, you can at a glance get some
sense of what the test case coverage is like for a chunk of
implementation, as well as scroll through the file quickly and see
what's not tested. (Fancy tools could also tell you this, in addition
to giving you code path coverage info that you can't get this way, but
no reason to throw away this simple approach as well.)
Submodules are one of my favorite newer features of Racket, and the
`test` module is a great use of them. Nowadays, I usually only use
separate files for testing when I have tests that are either very
expensive (such that you don't want them to run every time you hit Run
on the file in DrRacket) or for tests require external
resources/conditions or human interaction (e.g., a particular server
configuration).
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
