Thanks for the great suggestions.  I agree that I should really be testing the public interface rather than the implementation.  As a Racket n00b, I write small functions to compose the larger public facing functions, so testing these smaller/private functions prevents me for going off track.<div>
<br></div><div>Thanks again,</div><div><div><br clear="all">--<br>Chad Albers<br><br>
<br><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 7:05 PM, Eli Barzilay <span dir="ltr">&lt;<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">20 minutes ago, Chad Albers wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; As a Ruby dev, I really like unit testing.  I&#39;ve been using RackUnit<br>
&gt; to suits my needs.  I was wondering, though, about how people go<br>
&gt; about writing their tests for Racket.  Many of the functions that I<br>
&gt; write will not be part of the public API that a want to share from a<br>
&gt; module.  I can test the side-effects of these functions in the tests<br>
&gt; for the public functions that depend on the private ones.  I find<br>
&gt; it, though, handy  to test the non-public functions on their<br>
&gt; own.  Is there a way to run unit test against these &#39;private<br>
&gt; functions&#39;, without making them public via a (provide)<br>
<br>
</div></div>[I&#39;ll re-use an email I sent in a different place recently...]<br>
<br>
There are several approaches for this, the two popular ones are:<br>
<br>
1. One is to put most of the code in some internal module (which goes<br>
   in some `private&#39; directory), and have another module which<br>
   provides the public api.  With this you can write low-level tests<br>
   against this internal module in addition to the ones that are done<br>
   with the public api.<br>
<br>
2. Another approach is to go into the module via a back door.  For<br>
   example, rackunit has `require/expose&#39; which can pull out any<br>
   definition.  Another way to do this is to create a sandbox for the<br>
   module, which gives you an evaluator that works in the context of<br>
   the module.<br>
<br>
A new one:<br>
<br>
3. If you use nightly builds, you can put the test code in a<br>
   sub-module:<br>
<br>
     #lang racket<br>
     ...<br>
     (module+ test (require rackunit))<br>
     ...<br>
     (module+ test ...test code here...)<br>
     ...<br>
<br>
   The `test&#39; submodule (which is made from all of the (module+ test<br>
   ...) parts) is included in the bytecode, but it is not loaded or<br>
   executed when the module is required.  If you run the code directly<br>
   in drracket it would run it, or if you use the `raco test&#39; utility.<br>
<br>
   (Again, this is all new stuff that is not in 5.2.1.)<br>
<br>
(And BTW, I personally think that testing at the public interface<br>
level is *much* better whenever its possible.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:<br>
                    <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a>                   Maze is Life!<br>
</font></span></blockquote></div><br></div></div>