Unit testing is a very specific style of testing, whereby you test each unit (function/object/method) of code. It was (developed? popularized?) by the Extreme Programming crowd, and they use it in a context of test-first programming, also called test driven development.
If you write good enough tests, you will have just the right amount of code to finish the particular task at hand. Not too much, and not to little.
Note, that you do not necessarily have to practise test-first programming to unit test. Unit testing is simply writing tests for your code. Test-first programming is writing the tests before the code.
Chances are you're already unit testing, at least to one degree or another. Any time when you're coding, and you flip over to the [REPL] to see if your procedure is behaving the way you want it to, you are unit testing.
Instead of just putting random shotgun style tests in the [REPL], one could express the tests in a procedure. This way you can always execute that procedure as you work your way through your code. When you come back to that code months later you can be (more) confident that the routine still works by running the test, and you have examples as to how that code is actually used.
Once you have done that, then you can get into things like reporting and grouping tests into suites.
Check your scheme implementation. It might have its own unit testing package, if not....
C2 has got REAMS of content on unit testing - http://c2.com/cgi/wiki?CategoryTesting
http://www.extremeprogramming.org/rules/testfirst.html - More about Test First Programming
http://www.treese.org/scheme-boston/2003-02.html is a short transcript of a session on unit testing with the schematics unit test package