On the whole isolation thingy I would have to agree with Esko here. On
the running tests in parallell I couldn't care less but it's cool ;)
Though I agree with you Bill that this new instance per test is a bit
surprising, even confusing (perhaps) but it only really bites you if
you expect to be able to share state among tests which is a pretty bad
idea (for the most part) and that's how you learn about the new
instance per test thing and perhaps even the reasons for that.
The upside though is that the JUnit framework really, really tries to
make it hard to mess up due to shared state. Sure, there is a setup
and teardown method that you can, well, setup and tear down your state
but I'd rather have that state disappear automatically without having
to explicitly do it myself. If I have to explicitly remove it myself
chances are pretty big that I won't until I realize potentially after
hours of bug-hunting that against my better knowledge clearing up that
state actually was important.
To be frank, when I write tests/specs I don't really want to worry
about clean up. I want to spend as much time as possible focusing on
the code and don't worry about side-effects. It's all to easy to
forget to clean up something and false positives are the worst
possible outcome from forgetting. Having a clean slate (new instance
for each test) really helps with preventing those sideeffects. And
what is really the practical downside of of a new instance for each
test? I've never saw it as a limitation in JUnit. In fact, I've come
to depend on it.
Granted, this whole state-thingy would not be much of a big deal if
all your objects in your fixture were immutable. Immutability seems to
resonate with the scala-tradition so I thought thats why scalatest and
specs did not bother with the new instance though I was a bit put off
by it when I realized this was the case.
I love the scala-test BDD-DSL (only weird thing was a false possitive
when I added an enter after a "be"
The first case always passes :/ It would be better if it always failed.
> That all makes sense. My goal with ScalaTest is to facilitate
> different styles of testing, and you and Esko made me realize this is
> an important style to support. The default will continue to be the
> same, but getting the behavior you like will be easy: just mix in
> trait OneInstancePerTest.
I'm glad I managed to make some sense, that doesn't happen everytime
:) I appreciate your efforts to keep all of us happy :) Of course I
would be the happiest if a new fixture per spec/test was the default
and that you would have to mixin a trait to deviate from that. The
reason is that scalatest would be more in line with xUnit this way so
people that migrate from those frameworks would be less surprised.
Secondly the benefits of one instance per test is simplified
testing/specing though I would not have realized this myself if I did
not run into a situation where I noticed it (at least not as fast) so
having it as a default amplifies learning so to speak.
Perhaps the benefits of one instance per test would be more obvious if
the Trait was not named after the implementation. Something like:
or something (I realize it's hard to choose between spec/test in the
naming thats why I prefer the first suggestion but maybe neither is
good). My thoughts are that it would be easier to decide wether you
want a CleanFixtureForBeforeEach than wether you want a
> That alone won't get you distributed tests
> though. For that you'll need to also mix in trait TestDistribution,
> which will cause tests to be executed concurrently when a Distributor
> is passed to execute. This should work when running Specs
> Specifications through ScalaTest too.
Sounds really cool. I'd definitely would not want test distribution to
go with CleanFixtureBeforeEach so I agree with you that it should be
another mixin to control that.
> Also, I agree there's a gotcha with the be-return-paren form. I had
> never thought to try that. I'll see if I can't get it to generate a
> test failure with a helpful error message.
Thats understandable. It bit me when I was testing a CSS-parser and it
made sense to format the code that way to make the CSS AST:s more
readable in the specs. I can see how you overlooked that gotcha, sure
know I would've.
Västerlånggatan 79, 2 tr
111 29 Stockholm, SWEDEN
I'm impressed by your speed and time to market!