I like the "testing" part, but am uneasy with the "deploying" part.
Unit testing is so commonplace, and sometimes you want to have unit
tests of private stuff within a module, without having to break up the
module to expose the private stuff for testing. So, in that very
common, almost universal situation, being able to embed unit tests in a
module and have a way of switching them on and off at run time, seems good.
Beyond that, I think that talking about modes of running gets trickier
and more application-specific. Just a knee-jerk reaction without
looking at it, but hearing that there's a construct "with-deploying"
sounds seems like a dumbed-down, toy thing to do. I'd rather see an
extensible mechanism for run modes instead.
Just one example: just like some people might have mode called
"deploying" or "production", I might have particular modules that have a
run mode in which there are multiple implementations of the same
function, and at run time both the simple and the fast-and-fancy
algorithms are run and their results compared (and run modes in which
only one of the two algorithms are run). What modes I use for
``production'' might change during the development lifecycle, on a
per-module basis. I also have modes for profiling information,
including reports within the system. We also have modes in which
logging is done or not, and (ideally, though Racket's logging features
don't directly support this), this is on a per-module or
per-something-else basis. Some of these modes were originally intended
for ``development mode'' but were put into production at times. Whether
logging, profiling, algorithm-checking, etc. are done is not limited to
non-"production".
Also, even though I just said that embedded test cases are so universal,
and there is a convenience factor to being able to test unexported stuff
from a module, even this mode wants to be more complicated sometimes.
For example, sometimes tests are expensive, and you want to run a
smaller subset of the tests.
--
http://www.neilvandyke.org/