Thank you for this information. I had been trying to figure out how to test contracts from within a module+ only to give up and move my test cases to a different file.
I think this reinforces that I should be asking more questions on the mailing list. Alexander McLin > On Aug 26, 2014, at 5:53 PM, Matthias Felleisen <[email protected]> wrote: > > >> On Aug 26, 2014, at 5:43 PM, Kevin Forchione <[email protected]> wrote: >> >> >>> On Aug 24, 2014, at 2:09 PM, Matthias Felleisen <[email protected]> >>> wrote: >>> >>> Before you make fondue, ask. As you can see, people answer and answer >>> quickly. Indeed, Robby added an example to the Guide as he responded and >>> pushed it out into the repo. The next release will have an example due to >>> your posts. Thanks! >>> >>> Having said that, Racket is created by people who focus on systematic >>> design of software. The contract system is an example of this; >>> >>> -- it serves the purpose of creating software systematically (continuing >>> the so-called Design by Contract line of work) >>> -- it itself is developed systematically with inquires into the semantics >>> of contracts because we took contracts way beyond the primitive notion from >>> the 1980s and 1990s. >>> >>> But, the existence of ->i and ->d should give you a hint that we >>> occasionally make mistakes and we try to correct them without modifying >>> existing code. ->d is mostly okay, but ->i is better. When Robby created >>> ->i, he also used his experience with ->d to force programmers to list >>> dependency variables explicitly. That's why you have to say "(lst)", for >>> example. In addition, the language grows and with it, we have to grow the >>> contract system. Keyword arguments is an example of that kind. >>> >>> As for the philosophy behind our contract system, I think the guide's >>> opening section on boundaries brings across the idea that separates our >>> contracts from old-style stuff. It may not become immediately clear, but >>> when you program with contracts for a while, you will appreciate it. >> >> Wow! I am increasingly appreciating this approach (along with Racket’s >> systematic approach to design). >> >> I’m slowly converting my modules over to use contract-out and the ->i form >> makes it easy to see at a glance what the domains and ranges are, and I’m >> thinking the notation might be useful in the function definition’s comments >> as well. Is there a way to integrate unit testing into this approach? The >> (module+ test …) unit testing I’ve been doing is within the boundary of the >> mode and I wonder if there isn’t a way to simply move those test cases into >> another module (within the same file) and require it into the (module+ test >> …) form? > > > Yes, you can use submodules to import the outer module thru the contract > boundary and then run unit tests in the submodule: > > > #lang racket > > (provide > (contract-out > (f (-> integer? integer?)))) > > ;; --------------------------------- > ;; implementation > > (module+ test (require rackunit)) > > (define (f x) > x) > > (module+ test > (require (submod "..")) > (check-equal? (f 1) 1) > (check-equal? (f 'a) 'a)) > > > We should probably document this little trick somewhere. -- Matthias > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
