2011/6/28 Matthias Felleisen <matth...@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 <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
