And apologies for this completely wrong remark!
On Fri, May 22, 2015 at 7:19 AM, Robby Findler
wrote:
> Contracts mediate boundaries between parts of your program and sometimes
> tests should go across the boundary (to help test the contracts) and
> sometimes they should go inside (to test intern
>
> Adding to the suggestions, you can write something like `test-internal`
> and `test-external` submodules plus
>
> (module+ test
>(require (submod ".." test-internal)
> (submod ".." test-external)))
>
Enlightenment achieved
>
> At Fri, 22 May 2015 15:23:33 -0400, Matthias
Adding to the suggestions, you can write something like `test-internal`
and `test-external` submodules plus
(module+ test
(require (submod ".." test-internal)
(submod ".." test-external)))
At Fri, 22 May 2015 15:23:33 -0400, Matthias Felleisen wrote:
>
> DOn't forget
>
> $ rac
On May 22, 2015, at 8:19 AM, Robby Findler wrote:
> Contracts mediate boundaries between parts of your program and sometimes
> tests should go across the boundary (to help test the contracts) and
> sometimes they should go inside (to test internal functions). You have to
> pick one or the oth
DOn't forget
$ raco test --submoulde matthew-s-tests
On May 22, 2015, at 3:12 PM, Matthew Butterick wrote:
> Has this been an oversight? Do we need two "official" test submodules?
> One from the inside, and one from without.
>
> That’s a worthy point. I prefer to locate tests as close as p
If you want to have the contracts enforced in the test submodule, all you have
to do is add (require (submod “..”)) to the submodule.
You don’t need to use define/contract, and you don’t need to use module*
instead of module+.
You can just use
#lang racket
(provide
(contract-out
; convert
>
> Has this been an oversight? Do we need two "official" test submodules?
> One from the inside, and one from without.
That’s a worthy point. I prefer to locate tests as close as possible to the
code being tested. But the fact that 'raco test ...' and DrRacket only
recognize a single submodule n
You could always do something like (require (prefix-in contracted: (submod
".."))) to get separate bindings for the versions contracted by contract-out.
> On May 22, 2015, at 11:37, Anthony Carrico wrote:
>
> Has this been an oversight? Do we need two "official" test submodules?
> One from the
Has this been an oversight? Do we need two "official" test submodules?
One from the inside, and one from without.
--
Anthony Carrico
--
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
Contracts mediate boundaries between parts of your program and sometimes
tests should go across the boundary (to help test the contracts) and
sometimes they should go inside (to test internal functions). You have to
pick one or the other with a given test module tho.
Robby
On Friday, May 22, 2015
That's good to know. That means my previous conclusion is wrong
and I'm not forced to use define/contract when using test submodules.
Robby Findler writes:
> For that kind of situation, you should consider writing your test
> submodule like this:
>
> #lang racket
>
> (define (add1 x y)
> (inte
For that kind of situation, you should consider writing your test
submodule like this:
#lang racket
(define (add1 x y)
(integer? integer? . -> . integer?)
(+ x y))
(provide (contract-out [add1 (integer? integer? . -> . integer?)]))
(module* test racket
(require (submod ".."))
(add1 #f #
> Yes, there is :
> http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29
Thank you for the link. The "How to Program Racket" Guide will be really
helpful.
But I must admit I'm a little confused. Looking at the *fahrenheit* example in
the
Guide:
#l
On Fri, May 22, 2015 at 5:41 PM, Atticus wrote:
>
> Imho it would be nice if there was a small hint in the documentation
> about that case, perhaps there is and I didn't see it?
Yes, there is :
http://docs.racket-lang.org/style/Units_of_Code.html?q=define%2Fcontract#%28part._.Contracts%29
In
> ;
> #lang racket
>
> (define/contract (add1 x y)
> (integer? integer? . -> . integer?)
> (+ x y))
>
> (provide (contract-out [add2 (integer? integer? . -> . integer?)]))
> (define (add2 x y)
> (+ x y))
>
> (module+ test
> (require rackunit)
> (check-exn exn:fail? (λ _ (add1 20.5 21
>
> Are there any advantages/disadvantages of using test submodules vs
> separate test files? Or is it just a matter of personal preference?
>
> It looks like that test submodules are more convenient and flexible but
> I observed that test submodules increase the start up time of racket
> scripts.
> Three advantages of `test` submodules interspersed with the implementation
> code:
Here's a fourth: no need for tricks like require/expose to sneak around
interfaces.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this g
> I thought that the compilded code would have fewer debugging information
> (source code location etc) or not able to use the stepper. I have not
> used the stepper in racket yet (but the stepper in gambit scheme which
> is really useful at least for a beginner like me).
Oh I see what you mean. N
> Do you mean the case where you update your .rkt but don't re-make, so
> that the .zo is older? Racket will ignore the zo. As a result,
> although you lose the startup speed-up, you don't get any confusion
> from it running outdated code.
I thought that the compilded code would have fewer debuggi
>> (Otherwise the .rkt file must be parsed and expanded each/every time
>> you run. This includes test submodules, even though they won't be run.
>> In addition, expansion time can be significant with non-trivial
>> macros, including but not limited to Typed Racket.)
>
> Very interesting, this redu
> Startup will be fastest if you `raco make` the foo.rkt file to a
> compiled/foo.zo bytecode file. When you `racket foo.rkt` (directly or
> via #!) it will load the compiled/foo.zo provided it's not older.
Not "compiled/foo.zo"; it would be "compiled/foo_rkt.zo".
--
You received this message b
Great advice, thank you very much.
Neil Van Dyke writes:
> Three advantages of `test` submodules interspersed with the
> implementation code:
>
> * You're usually working on implementation and tests at the same time,
> and putting them adjacent in the same file is helpful (without fancy IDE
>
On 05/21/2015 08:44 AM, Neil Van Dyke wrote:
> Three advantages of `test` submodules interspersed with the
> implementation code:
It is worth mentioning that submodules don't work well with typed racket
yet, so TR tests are often in another file.
--
Anthony Carrico
--
You received this messag
> I usually prefer test submodules because I like the proximity to the
> code being tested. Plus in Emacs racket-mode I can fold/hide the test
> submodules if they ever become distracting.
Nice feature. Btw thank you for making racket-mode :)
> Exceptions to "usually":
>
> - Even with the ability
Three advantages of `test` submodules interspersed with the
implementation code:
* You're usually working on implementation and tests at the same time,
and putting them adjacent in the same file is helpful (without fancy IDE
support).
* These tests constitute documentation for someone who ha
I usually prefer test submodules because I like the proximity to the
code being tested. Plus in Emacs racket-mode I can fold/hide the test
submodules if they ever become distracting.
Exceptions to "usually":
- Even with the ability to hide/fold tests, if the ratio of tests to
tested is really lar
26 matches
Mail list logo
