[MIT-Scheme-devel] Tests

[Taylor R Campbell]

We don't tend to have many policies around here besides trying not to
break the X.(Y+1) build from X.Y, but I'd like to adopt a policy that:

- any new or rewritten code in master should have automatic tests for it
- any new bug fixes should be done in two commits:
  1. adding a test that uses expect-failure or expect-error
  2. fixing the bug and removing the expect-failure or expect-error
     (possibly later; grep for those to see some known bugs)

This doesn't mean you have to do test-driven development if that's not
your cup of tea.  But it does mean (a) if I need to do maintenance on
(new) subsystems then there'll be some tests that can help me to avoid
introducing bugs and stepping on toes, and (b) if you think you
squished a bug there'll be a verifiable audit trail to confirm you
actually squished it at least in one case.

I've been guilty of breaking old subsystems _and_ committing changes
that fail to fix the bugs they were supposed to fix.  So far, adhering
to these for myself, it's made development a lot faster and easier
even though at face value it seems like a little more work, because I
can get confidence in my work a lot faster and detect bugs sooner
while the code is still paged into my head.

Thoughts?