[Rspec-devel] use case for: setup_once, teardown_once
aslak hellesoy
aslak.hellesoy at gmail.com
Sat Jun 10 02:15:46 EDT 2006
On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "aslak hellesoy" <aslak.hellesoy at gmail.com>
>
> >> - would it be appropriate to be testing expensive/slow things?
> >
> > Yes, but you should isolate slow code in separate classes and have a
> > separate set of specs for those classes only.
>
> If I have 5 components, and the communication channels between them are
> slow, and my acceptance test is about a round trip from outside, through all
> 5, and back (possibly including things like response time): what should I
> isolate?
>
> > This is where you should be able to use mocks for the expensive stuff,
> > when running specs for the remaining 10%.
>
> I do understand (and agree with) this advice in the context of unit testing.
> I don't see how I could apply it to an integration or acceptance test.
>
Integration/Acceptance/EndToEnd tests where all code is playing in
concert - usually using heavy resources like I/O, Threads, Graphic
environments etc...
They're usually slow.
I'm not sure RSpec is the right tool for that kind of things.
RSpec's focus is on a smaller level - designing (and verifying)
individual classes' behaviour and their communication with immediate
neighbours (using mocks).
While you can certainly use RSpec to poke a fully wired set of many
objects and see if it chokes, I'ts certainly not what RSpec is
designed for. -Because when you're doing this kind of activity, you're
no longer designing, but testing.
I'm a huge fan of this kind of tests though - don't get me wrong.
Maybe RSpec is good for this stuff too - I just haven't tried it yet.
Aslak
> Thanks!
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
More information about the Rspec-devel
mailing list