5.12 Testing
Now it’s the moment of truth: the time to find out whether your function definition works.
If you’ve typed everything into the Definitions pane correctly, just click the “Run” button.
If you’re using “should be” for test cases, you’ll see the results in the Interactions pane,
each followed by the words “should be” and the right answer. Check that each of the
actual answers matches what you said it “should be”: if any of them don’t match, figure
out what’s wrong and fix it. If, on the other hand, you’re using check-expect, you should
see a report telling you exactly how many and which of your test cases failed.
If you get an error message like reference to an identifier before its definition, it
means that you tried to use the new function before defining it — for example, if you
have “should be”-style examples appearing ahead of the definition. (Examples using
check-expect are allowed to appear ahead of the definition.) A slightly different error
message, name is not defined, not an argument, and not a primitive name, means that
the name of the function in the examples doesn’t exactly match the name of the function
in the definition (in spelling, or capitalization, or something like that).
If you get an error message like this procedure expects 2 arguments, here it is provided
1 argument, it means your contract, examples, and skeleton disagree on how many arguments the function is supposed to take in. An error message like expects type
as 1st argument, given “hello” likewise indicates a disagreement among contract, examples, and skeleton on either the types or the order of the arguments.