[racket-dev] Testing mode

Apologies. I didn't understand your original message then, and all I understand now is that I misunderstood it. 

But I will say that I already organize my files according to Eli's style. I have considered writing tests right below a function, but in the end I decided that this wasn't any good for most cases. Many tests involve several functions. So my files tend to have several test suites, one per cluster. For the sake of consistency, I always place all test suites at the end. 

-- Matthias




On Jun 28, 2011, at 10:52 AM, Jay McCarthy wrote:

> 2011/6/28 Matthias Felleisen <matthias at ccs.neu.edu>:
>> 
>> 
>> 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.
> 
> My patch was supposed to address this by setting up a protocol for
> code to be test only or "not" test (that's what I intended by
> with-deploying.)
> 
> You'd write code like...
> 
> (define (f x) ...)
> 
> (check-equal? (f 5) 10)
> 
> and when run in "raco test" or DrRacket it would run the test, but
> otherwise would only run a check to see that it wasn't in testing
> mode.
> 
> I was worried about situations where you had some code that had module
> toplevel code that starts up a long running process that shouldn't be
> run in test mode, so I wanted to cordon off that. I wasn't imagining
> anything as complicated as what Neil or Eli seem to want. (Seems like
> overkill to me.)
> 
> The "test all" functionality comes from running "raco test --all" on
> your main program, to test all its sub-components, rather than having
> to make a new artificial testing file.
> 
> I dislike Eli's proposal because I don't think it gets tests close to
> their functions with low syntactic overhead. For example...
> 
> (define (f x) ...)
> (check-equal? (f 5) 10)
> 
> ; 200 lines of more stuff
> 
> (define (g x) ...)
> (check-equal? (g 7) 14)
> 
> becomes
> 
> (define (f x) ...)
> 
> ; 200 lines of more stuff
> 
> (define (g x) ...)
> 
> (define (test)
> (check-equal? (f 5) 10)
> (check-equal? (g 7) 14))
> 
> or worse
> 
> (define (f x) ...)
> (define (test-f)
> (check-equal? (f 5) 10))
> 
> ; 200 lines of more stuff
> 
> (define (g x) ...)
> (define (test-g)
> (check-equal? (g 7) 14))
> 
> (define (test)
> (test-f)
> (test-g))
> 
> Jay
> 
>> 
>> -- 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
>> 
>> 
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>> 
> 
> 
> 
> -- 
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
> 
> "The glory of God is Intelligence" - D&C 93