Jay McCarthy wrote at 06/28/2011 10:52 AM:
My patch was supposed to address this by setting up a protocol for
code to be test only or "not" test (that's what I intended by
with-deploying.)
It was "deploying" in the name that I thought was problematic.
"when-testing-mode" and "unless-testing
20 minutes ago, Jay McCarthy wrote:
> I was worried about situations where you had some code that had
> module toplevel code that starts up a long running process that
> shouldn't be run in test mode, so I wanted to cordon off that. I
> wasn't imagining anything as complicated as what Neil or Eli s
Apologies. I didn't understand your original message then, and all I understand
now is that I misunderstood it.
But I will say that I already organize my files according to Eli's style. I
have considered writing tests right below a function, but in the end I decided
that this wasn't any good
On Jun 28, 2011, at 10:02 AM, Eli Barzilay wrote:
>
> I do see a point in such a feature -- for example, IIUC, Matthew's
> recent optimization to loading phase-1 code could be expressed inside
> the language by making all `for-syntax' requires default to lazy
> loading mode. But I doubt that su
2011/6/28 Matthias Felleisen :
>
>
> I have come to accept that all modules should come with their tests included,
> as an exportable test suite:
>
> -- you don't need to expose any 'private' identifiers
> -- they are next to the function they test
> -- it is easy to run them from the repl after l
About a minute ago, Matthias Felleisen wrote:
>
> I have come to accept that all modules should come with their tests
> included, as an exportable test suite:
>
> -- you don't need to expose any 'private' identifiers
> -- they are next to the function they test
> -- it is easy to run them from th
I have come to accept that all modules should come with their tests included,
as an exportable test suite:
-- you don't need to expose any 'private' identifiers
-- they are next to the function they test
-- it is easy to run them from the repl after loading the file
-- ... and from some 'te
25 minutes ago, Neil Van Dyke wrote:
>
> Just one example: just like some people might have mode called
> "deploying" or "production", I might have particular modules that
> have a run mode in which there are multiple implementations of the
> same function, and at run time both the simple and the
I like the "testing" part, but am uneasy with the "deploying" part.
Unit testing is so commonplace, and sometimes you want to have unit
tests of private stuff within a module, without having to break up the
module to expose the private stuff for testing. So, in that very
common, almost univer
On Mon, Jun 27, 2011 at 8:03 PM, Jay McCarthy wrote:
>
> It also adds "raco test" which runs a file in testing mode. You can
> optionally add the "--all" option so that all dynamically required
> modules are run in testing mode as well. There could also be a testing
> button in DrRacket, but I did
6 hours ago, Eli Barzilay wrote:
> 15 minutes ago, Jay McCarthy wrote:
> > We've talked before about having a testing mode so that tests could
> > be written inline, but not run when the module is normally run. I've
> > attached a patch that adds a simple way of doing this.
> >
> > racket/test giv
15 minutes ago, Jay McCarthy wrote:
> We've talked before about having a testing mode so that tests could
> be written inline, but not run when the module is normally run. I've
> attached a patch that adds a simple way of doing this.
>
> racket/test gives you
> - with-testing
> - with-deploying
W
12 matches
Mail list logo
