[plt-scheme] Test the Program

I'll add one more tidbit to Stephen's answer.

The textbook you're using, How To Design Programs, hasn't yet caught  
up to the latest pedagogical features of DrScheme. The newer versions  
of DrScheme are centered around what some would call "test-driven  
development" in which the student must write tests for their functions  
rather than manually trying them out. Consequently, if you omit the  
tests, DrScheme gives you a warning that the program hasn't been  
tested. Pedagogically, typing in ad-hoc expressions after the function  
has been written doesn't count as testing it.

If you want to follow the text, I'd suggest two things:

1. Introduce the students now to writing the check-expect tests that  
Stephen and others have shown.
or
2. Skip the automated tests for now and tell the students to ignore  
the warning. The book introduces the idea (if not the syntax) of  
automated tests in section 2.5.

There is a second edition of the book in progress. Testing is an  
integral part of the design recipe and the syntax for doing automated  
tests is introduced early.

http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html

-B

On Sep 3, 2009, at 12:33 PM, Stephen Bloch wrote:

>>> Asher, Gregg wrote:
>>>> When I define a program in the definitions window and then enter  
>>>> the program name in the interactive window substituting a value  
>>>> for the parameter and then "Run" (my version of Dr. Scheme  
>>>> doesn't have an "Execute" button) the program I don't the results  
>>>> of the program but a message "This program should be tested.
>
> You've gotten several different correct answers to this, each  
> addressing a different aspect of what's going on.  Let me try to put  
> them all together in context.

> 2) You're getting a message that says "This program should be  
> tested."  This happens when you "Run" a Definitions pane that  
> doesn't contain any test cases written with "check-expect" (or its  
> friends).  To solve this, write test cases in the Definitions pane,  
> preferably for each function you define.  For example, the  
> Definitions pane might look like this:
>
> ; area-of-disk : number(radius) -> number
>
> (check-expect (area-of-disk 0) 0)
> (check-within (area-of-disk 1) 3.14 .01)
> 	; the third parameter is a "close enough" criterion, since this  
> function does inexact computations
> (check-within (area-of-disk 2) 12.56 .01)
>
> (define (area-of-disk radius)
> 	(* pi radius radius))
>
> ; cube : number -> number
>
> (define (cube num)
> 	(* num num num))
>
> (check-expect (cube 0) 0)
> (check-expect (cube 4) 64)
> (check-expect (cube -5) -125)
>
> Note that "check-expect", "check-within", etc. can appear either  
> before or after the definition of the function they're supposed to  
> test; you can decide for yourself which fits your pedagogical style  
> better.  The advantage of "before the definition" is that students  
> can follow the design recipe without "backing up" in the Definitions  
> pane: contract, test cases, skeleton becoming a definition.
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme