CSC161 2010F, Class 25: Interactive Testing

Overview:
* Reflection.
* Two stories.
* Lab.
* Better testing.

Admin:
* EC for attending fencing: Tuesdays/Thursdays at 7pm.
* EC for Sunday's concert, 2pm SL.
* EC for Sunday's 10pm PhreeNet meeting.
* Recommendations for the weekend: Harold & Maude, The Contingency Plan.
* Reading for Monday: Pages 40-44 of Bertrand Meyer's 
  Applying "Design by Contract"
* If you choose to attend 10/10 this weekend, please drink responsibly.
  * My other class asked that I provide a carrot to encouage you to
    behave responsibly, so I'm bringing carrots to class on Monday.  You
    can have one if you avoid 10/10 or behave responsibly at 10/10.
    (If the "traveling 10/10" is available to you, the same expectations
    hold.)

Reflection: What did we learn in CSC 161 on Wednesday?
* Buzzword: Unit testing* Test early and often.
* ien interactive tester for selection_sort. Your tester should read up to 1024 integers from standard input and print them out in sorted order. Call your tester sort.c (executable sort). Use the interactive tester on some inputs you find useful. Correct any errors you detect in selection_sort. st individual parts
  (Other kinds of testing look at the whole)
* Build tests that let you see the binary "Did it succeed or not?" rather
  than "What did it do for this case?  What did it do for this case? 
  What did it do for this case?"
* We did the example of average
  * Check boundary cases!
  * Have a wide ranging set of tests
* Testing can make sure that you cover your bases
* Tests can help a group reach consensus on what the code is supposed
  to do.
* Pundits tell you to write your tests (and documentation) first so that
  you know what you're supposed to be writing
  * They have good arguments for this, too.a
* Test early and often.