Hi list,
Does anyone have experience using Rspec for both the feature and spec
cycle with Autotest?
What I mean is that I’m developing a library that will only be used by
other developers. However, if I only write specs and not acceptance
tests, I have no idea if it’ll work, and if I hit real resources in
the specs, coding is really slow because I don’t find out if I have a
silly error until I wait for half the tests to run.
What I’d like to do is something like this: run all my specs with real
resources as acceptance tests, then drop down into running the specs
with mocks until they all pass, then jumping out to the “feature
layer” of real resources, all automatically with Autotest.
I haven’t gotten into specifics yet, just brainstorming, and wanted to
know if someone has a good way to deal with this type of situation.
Thanks.
Sean DeNigris
Sean DeNigris wrote:
Hi list,
Does anyone have experience using Rspec for both the feature and spec
cycle with Autotest?
Yes!
What I mean is that I’m developing a library that will only be used by
other developers. However, if I only write specs and not acceptance
tests, I have no idea if it’ll work, and if I hit real resources in
the specs, coding is really slow because I don’t find out if I have a
silly error until I wait for half the tests to run.
What I’d like to do is something like this: run all my specs with real
resources as acceptance tests, then drop down into running the specs
with mocks until they all pass, then jumping out to the “feature
layer” of real resources, all automatically with Autotest.
Probably not a great idea to use mocks. What real resources are slowing
you down?
For the rest, if you use Cucumber for your acceptance tests (which you
should!), then autotest will act as you described by default if
AUTOFEATURE is true.
I haven’t gotten into specifics yet, just brainstorming, and wanted to
know if someone has a good way to deal with this type of situation.
Thanks.
Sean DeNigris
Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Probably not a great idea to use mocks. What real resources are slowing
you down?
It’s an application scripting library, so pretty much every method
call interacts with an application (mostly Apple events) - there are
windows popping up all over the place, lol. I just want to use mocks
in the specs i.e. unit tests, and use real resources in the outer
cycle
For the rest, if you use Cucumber for your acceptance tests (which you
should!), then autotest will act as you described by default if
AUTOFEATURE is true.
That’s what I’m doing now. What I was wondering was if anybody was
using rspec for the specs and rspec again for the features (instead of
cucumber). Maybe by encapsulating the choice to use mocks or not as
the difference between the two cycles…
It seems like using Cucumber for the features when developers are the
users will obscure the usage, and I don’t see the benefit to plain
English in this case.
Sean
Thanks for the reply!
Sean DeNigris wrote:
Probably not a great idea to use mocks. �What real resources are slowing
you down?
It’s an application scripting library, so pretty much every method
call interacts with an application (mostly Apple events) - there are
windows popping up all over the place, lol.
So? That shouldn’t bother you.
I just want to use mocks
in the specs i.e. unit tests, and use real resources in the outer
cycle
Unless performance is a serious issue, your tests will probably be
better done with real resources. Of course, you can use mocks on
demand, which means you don’t have to ysethem everywhere.
For the rest, if you use Cucumber for your acceptance tests (which you
should!), then autotest will act as you described by default if
AUTOFEATURE is true.
That’s what I’m doing now. What I was wondering was if anybody was
using rspec for the specs and rspec again for the features (instead of
cucumber). Maybe by encapsulating the choice to use mocks or not as
the difference between the two cycles…
It seems like using Cucumber for the features when developers are the
users will obscure the usage, and I don’t see the benefit to plain
English in this case.
Features are usually best expressed in nontechnical language. That’s
why Cucumber makes so much sense. If you think it’s not so for your
case, let’s see some of your features! It’s possible that they’d be
better as unit tests…
Sean
Thanks for the reply!
Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]