And apologies for this completely wrong remark!
On Fri, May 22, 2015 at 7:19 AM, Robby Findler
ro...@eecs.northwestern.edu 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
;
#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.5)))
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 #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:
#lang
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 ro...@eecs.northwestern.edu writes:
For that kind of situation, you should consider writing your test
submodule like this:
#lang racket
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,
On Fri, May 22, 2015 at 5:41 PM, Atticus attic...@posteo.org 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 :
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 it,
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 acarr...@memebeam.org wrote:
Has this been an oversight? Do we need two official test submodules?
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 named
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
DOn't forget
$ raco test --submoulde matthew-s-tests
On May 22, 2015, at 3:12 PM, Matthew Butterick m...@mbtype.com 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
On May 22, 2015, at 8:19 AM, Robby Findler ro...@eecs.northwestern.edu 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
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
$ raco test
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 Felleisen
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
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
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 message
Great advice, thank you very much.
Neil Van Dyke n...@neilvandyke.org 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
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 to
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 because
(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 reduced the
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
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. No,
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.
If
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 debugging
26 matches
Mail list logo
