[racket-dev] Testing mode

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Tue Jun 28 08:54:25 EDT 2011

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/


Posted on the dev mailing list.