Re: [racket-users] Unit test inner procedures

Regarding submod testing, would it make sense to have a submod* form that recursively imports? I've recently become a fan of this approach to testing inner procedures but it seems to require both (submod "." ) (submod "." test), or maybe a version that specifically imports all tests recursively.

Re: [racket-users] Unit test inner procedures

I like it. Added an issue 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

Re: [racket-users] Unit test inner procedures

(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

Re: [racket-users] Unit test inner procedures

> > 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, d

Re: [racket-users] Unit test inner procedures

+2(that’s what the style guide says, too) 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

[racket-users] Unit test inner procedures

Sometimes I find myself thinking: "I should really write some tests for all of this!" But then I ask myself: "Uhm, how can I test some of the inner procedures of this procedure?" I sometimes use inner procedures when no other part of the code needs access to some procedure and it fits purpose-w