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