Matthias wrote: > I see two sequences: > > -below ;; disables up to > > -above ;; here; disables up to -below and re-enables tests > > or > > -above ;; disables everything up to here and enables tests up to > > -below ;; here; disables tests below. > > Anything else? -- Matthias
Those are probably the only REASONABLE sequences, but novice programmers will always find unreasonable ways to do it -- and those are the students I'm most worried about. To reduce the space of possible mistakes, I'm sorta leaning towards a (with-tests-disabled ...) macro that cannot be nested. Although as various people have pointed out, a typical workflow is more likely to ENABLE tests for a particular part of the program than to DISABLE tests for a particular part of the program. We could address this by disabling check-expect by default, and providing a (with-tests-enabled ...) macro... but that would seriously break backwards compatibility for hundreds of teachers. Robby wrote: > If that's correct, then I think we have two better routes to pursue: > > - multi-file programs I'm all in favor: I've been requesting a useful "require" in student languages for years. I presume you don't work in a parent file until its children have all passed their test cases, so that helps a bit. Do you then automatically disable tests in any file that's "require"d? If so, there's no easy way to "run all the test cases for all the functions in this program"; if not, I don't see how it addresses the problem. > - better support in the GUI for showing us only some of the test > results (perhaps something to focus in on test cases that test > specific functions or something like that). Yes, that would be nice too, if we can come up with a UI that's both suitably minimal and suitably usable. Stephen Bloch sbl...@adelphi.edu _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev