[racket-dev] [racket] Disable/Enable Tests

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



On Nov 28, 2011, at 10:09 PM, Robby Findler wrote:

> Those two seem like they can combine in strange ways.
> 
> Robby
> 
> On Mon, Nov 28, 2011 at 9:08 PM, Matthias Felleisen
> <matthias at ccs.neu.edu> wrote:
>> 
>> I can see adding both disable-tests-above and disable-tests-below.
>> 
>> 
>> On Nov 28, 2011, at 3:44 PM, Vincent St-Amour wrote:
>> 
>>> At Mon, 28 Nov 2011 11:54:06 -0500,
>>> Matthias Felleisen wrote:
>>>> I propose
>>>> 
>>>> 1. to remove the menu and its functionality
>>>> 2. to add a macro disable-tests-below
>>>> 3. and be prepared to add a macro enable-tests-below.
>>> 
>>> `disable-tests-below' makes it easy to accidentally skip running tests
>>> altogether.
>>> 
>>> Consider this scenario:
>>> - A student works on an assignment, one problem at a time.
>>> - Once a problem is done, he doesn't touch the code anymore, and
>>>  wants to disable the tests.
>>> - With `disable-tests-below', he needs to add it at the top of the
>>>  file, and to add `enable-tests-below' before the problem he's now
>>>  working on.
>>> - If he forgets to add `enable-tests-below', no tests get run at all.
>>> 
>>> `disable-tests-above' would accomodate this workflow better. If the
>>> student forgets to move it as he solves problems, then more tests get
>>> run. No problem. That sounds like a better default to me.
>>> 
>>> However, I'm a bit uncomfortable with `disable-tests-above' affecting
>>> the behavior of what comes before it. It may lead to confusing
>>> situations.
>>> 
>>> A region-based solution also sounds good. Especially since (I assume)
>>> only a small number of tests are actually expensive.
>>> 
>>> Vincent
>> 
>>