[Rspec-devel] use case for: setup_once, teardown_once

[aslak hellesoy]

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> Bump.
>
> > In this case I was actually using spec to specify some explicit
> > requirements about the (remote) results of a (remote) deployment, to say
> > things like:
> >
> > - the remote directory structure should satisfy ...
> > - remote file time stamps should be ...
> > - remote access controls should be ...
> >
> > How would mocks help with this? Or is this not an appropriate thing to
> > specify?
>
> A bit more generally, if my tests are closer to integration or acceptance
> tests than unit tests (where my guess is one should test the actual
> assemblage without mocking of in-scope parts):
>
>  - 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.

You should be able to run (superfast) specs for 90% of your code.
You'll run the fast suite often and the slow suite less often.

This means that 90% of your code shouldn't depend directly on the remaining 10%
of your code that _is_ slow (i.e. the code that does I/O and Thread stuff).

This is where you should be able to use mocks for the expensive stuff,
when running specs for the remaining 10%.

>  - would it be reasonable to want to not repeat setup costs for each test?
>

If you isolate the expensive stuff, it won't slow down the rest - so
it's less important.

Aslak

> Thanks.
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>