[racket-dev] Testing mode

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Tue Jun 28 09:55:47 EDT 2011

I have come to accept that all modules should come with their tests included, as an exportable test suite: 

-- you don't need to expose any 'private' identifiers 
-- they are next to the function they test 
-- it is easy to run them from the repl after loading the file 
-- ... and from some 'test all' file 

BUT, I'd like two additions: 

-- run the tests automatically when the file is required in a certain into racket or always into DrRacket's repl 
-- if code size is a concern, racket should be able to eliminate tests 

That's what I asked for, and this is what Jay's patch is supposed to address though I don't see how it does. Also, like Eli, I don't like the additional wrappers and with-deployment looks suspicious. 

-- Matthias

On Jun 28, 2011, at 8:54 AM, Neil Van Dyke wrote:

> 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/
> _________________________________________________
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev

Posted on the dev mailing list.