[racket-users] Re: Unit test inner procedures

[Zelphir Kaltstahl]

Huh, that looks reasonable.
So far I've not used modules much, except the implicit one by:
~~~
#lang racket
~~~
So the example is helpful.
The tests are not in another file, but at least they are not inside a 
wrapping procedure and are in a way separate.
Maybe I should have a look at the different ways of defining modules again 
and use them more.

On Monday, November 27, 2017 at 10:15:38 PM UTC+1, Jack Firth 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
>
> (provide
>   (contract-out
> [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.

Re: [racket-users] Re: Unit test inner procedures

['John Clements' via Racket Users]

+1. Totally agree.

> On Nov 27, 2017, at 1:15 PM, Jack Firth  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
> 
> (provide
>   (contract-out
> [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 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Unit test inner procedures

[Jack Firth]

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

(provide
  (contract-out
[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.