+1. Totally agree.
> On Nov 27, 2017, at 1:15 PM, Jack Firth <jackhfi...@gmail.com> wrote:
> I don't think you can directly test an inner procedure while keeping your
> test code separately loadable (e.g. different file or module). It doesn't
> seem like a good idea to me, personally. Inner procedures communicate to me
> that I can change, reorganize, delete, and otherwise do whatever I want to
> them without breaking any code outside the definition of the outer procedure.
> Breaking tests in a different file with a refactoring of an inner procedure
> would be very surprising to me.
> Instead, I recommend not using inner procedures so extensively. Instead
> define functions within modules (or possibly submodules) and use `provide`
> with `contract-out` to declare which functions make the public API of your
> module. You can then add a test submodule which has access to the inner
> workings of the outer module and test "private" helper functions that way.
> Here's an example:
> #lang racket;; note that using #lang implicitly creates a module around the
> whole file
> [my-public-function (-> input? output?)]))
> (define (my-public-function input)
> (helper2 (helper1 input)))
> (define (helper1 input) ...)
> (define (helper2 input) ...)
> (module+ test ;; inside this submodule we can see helper1 and helper2, even
> though they're not provided
> (require rackunit)
> (check-equal? (helper1 test-input) test-output)
> ... more tests here ...)
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.