We don't test contracts. In general contracts are relatively simple functions,
but yes, we have written several papers on bugs in contracts and how this
complicates a contract monitoring system.
If you are asking how to test functions that have contracts, I import that
module itself into a su
--On 23 août 2013 15:09:04 +0900 Chad Albers wrote:
From the many responses, it looks like Dr Racket is more popular than
I thought. I'm a long-time Emacs user, and although I have tried Dr
Racket, Emacs is now part of my bones. (I'm excited to learn that
there is a Racket mode...and hope it
On Fri, Aug 23, 2013 at 2:09 AM, Chad Albers wrote:
> From the many responses, it looks like Dr Racket is more popular than
> I thought. I'm a long-time Emacs user, and although I have tried Dr
> Racket, Emacs is now part of my bones. (I'm excited to learn that
> there is a Racket mode...and hop
One more point: we are in the process of re-arrange the code
base so that it uses the package system just like any outside
contributor does. We already run every git-push thru a complete
test engine called drdr, and all contributed packages may opt
into this mechanism (so that any change will te
Thanks everyone for their feedback. Keep it coming! I didn't know
about the ability to include tests next to the source code a la
literate-programming. A fantastic feature. I'll try it out
personally. I am, though, concerned that my tests will obscure the
code that executes it.
>From the many
On Fri, Aug 23, 2013 at 12:14 AM, Greg Hendershott <
greghendersh...@gmail.com> wrote:
> In my opinion the "most Rackety" way to do tests these days is what
> Laurent mentioned: The `test` submodule.
>
When the tests become too long, I prefer to put them in a separate file
though.
> (Although w
In my opinion the "most Rackety" way to do tests these days is what
Laurent mentioned: The `test` submodule.
1. It's easy to run the tests in foo.rkt file: `raco test -x foo.rkt`.
2. It's easy to write the tests -- no extra source file required.
3. You can even write tests adjacent to the defini
Thanks for the idea but I think it's worth explaining the
bigger picture a bit in addition to the detail answers you
have received.
;;
Part of Racket's slogan is
'internalize tools from the tool chain into the language'
Tests have re
People go back and forth on tests/A and A/tests, but I think the current
thought is that A/tests is better than tests/A (altho with the package
manager, the original rationale for that (keeping the code and the tests
more together) seems to be gone.
But yeah, I'd definitely agree that a top-level
Quickly: It is common to use a submodule for tests, in the same source
file:
(module+ test
(require rackunit)
)
then running `raco test ...` will run all the tests. Such tests
are also automatically run in DrRacket when you press run (along with the
'main' submodule).
For packages that
As a Ruby engineer, we have a wonderful tool called "guard" that
automatically runs our unit-tests every time a test-case changes or
every-time a source file changes.
I have written a guard plugin that performs the same task for Racket's
rackunit. Currently, it pretty primitive - guard runs all t
11 matches
Mail list logo
