I like it. Added an issue <https://github.com/racket/rackunit/issues/85> to 
figure out a Rackety way to do this; feedback strongly encouraged.

On Tuesday, November 28, 2017 at 11:05:50 AM UTC-8, Benjamin Lerner wrote:
>
> (Pyret co-lead dev here.)
>
> The way nested tests work for us in Pyret is actually simpler than that: 
> As a dummy example, consider a curried addition function
>
> fun make-adder(num1 :: Number):
>   fun result(num2 :: Number):
>     num1 + num2
>   where:
>     result(5) is num1 + 5
>     result(10) is num1 + 10
>   end
>   result
> where:
>   make-adder(3)(6) is 9
>   make-adder(4)(2) is 6
> end
>
> This definition will run *six* test cases — the two test cases for 
> make-adder will each run the two nested test cases for result. These will 
> be reported as three blocks of test cases: one block for make-adder and 
> two blocks for result. The test cases for result run in the lexical scope 
> of the body of make-adder, so they have closed over num1 as part of their 
> environment.
>
> (In practice, this can lead to many, many test cases, obviously. So when 
> running a program in Pyret, by default we only run the test cases lexically 
> present in the main module of the program.)
>
> ~ben
>
> On 11/28/2017 01:53 PM, Jack Firth wrote:
>
> BUT, one could easily imagine an extension to the unit testing framework 
>> where inner tests work, too. With a combination of coverage and unit 
>> testing, you can usually get these inner unit tests to run and record their 
>> status the same way outer ones do in module+. Pyret, for example, does 
>> exactly this, so we should be able to do it too.
>>
>
> Looking at Pyret, you're referring to the "where" syntax right? So this:
>
> fun sum(l):
>   cases (List) l:
>     | empty => 0
>     | link(first, rest) => first + sum(rest)
>   end
> where:
>   sum([list: ]) is 0
>   sum([list: 1, 2, 3]) is 6
> end
>
> ...means that the "where" body is composed of tests of the `sum` function. 
> I like this a lot and want it for Racket (in a way that's more direct than 
> submodules). But I have no idea how it should work for nested functions 
> that close over variables of the outer function. Would the tests specify 
> the closure bindings maybe?
> -- 
> 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...@googlegroups.com <javascript:>.
> 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.

Reply via email to