On my current rails project we’re using both rspec and cucumber.
We’ve been diligent about keeping our specs as true unit tests, using
nulldb and mocking/stubbing to disconnect the specs from the database
and keep each spec focused on the class/method under test. Our
cucumber features are integration tests and use the database (as they
should). This separation has worked well for us up to now. Our specs
have remained fairly fast, even as our spec suite has grown (around
1200 specs, currently).
I’ve started working on building an REST-inspired HTTP API for the
app. Initially, I’ve continued to use cucumber to integration test
the API. However, I’m now convinced that as great as cucumber is for
integration testing the user-facing parts of our application, it’s not
the right tool for integration testing the API. I’d like to write my
API integration tests using just rspec and rack-test. But I really
like the fact that “rake spec” runs only the unit tests, and is much
faster than running all of the tests. I don’t want to give that up.
Is there an easy way to setup multiple spec suites within a single
rails app? I’d like to run the integration test specs separately from
the unit test specs.
app. Initially, I’ve continued to use cucumber to integration test
the API. However, I’m now convinced that as great as cucumber is for
integration testing the user-facing parts of our application, it’s not
the right tool for integration testing the API. I’d like to write my
API integration tests using just rspec and rack-test. But I really
like the fact that “rake spec” runs only the unit tests, and is much
faster than running all of the tests. I don’t want to give that up.
Is there an easy way to setup multiple spec suites within a single
rails app? I’d like to run the integration test specs separately from
the unit test specs.
In rspec-1 you pretty much have to do it by directories. In rspec-2 you
can use arbitrary hash key/values as filters:
describe “something”, :suite => “my fast suite” do
…
end
RSpec.configure do |c|
c.filter_run :suite => “my fast suite”
end
As of now there is not an easy way to hook into that to create different
“profiles” like Cucumber, but it’d be pretty easy to add and we should
definitely do so before rspec-2 goes final. Because the filtering can be
arbitrarily complex (using lambdas), we need to keep it in ruby, but
maybe we have a DSL for named filters that we can key off on the command
line. Something like:
RSpec.configure do |c|
c.filter :fast, :suite => “my fast suite”
end
The new tagging support in rspec 2 looks fantastic, but I don’t think
we’re ready to upgrade to rspec 2 yet, especially since it’s still in
beta.
How does the directory approach work with rspec 1? (And feel free to
point me to a blog post or wiki entry that documents this–I’ve done
some googling but haven’t found anything yet).
app. Initially, I’ve continued to use cucumber to integration test
the API. However, I’m now convinced that as great as cucumber is for
integration testing the user-facing parts of our application, it’s not
the right tool for integration testing the API.
I know this isn’t why you’re here, but can I ask why not? At Songkick we
actually went the other way and ended up converting rspec-based
integration tests for the API into cukes when we got the hang of testing
it via Cucumber.
The new tagging support in rspec 2 looks fantastic, but I don’t think
we’re ready to upgrade to rspec 2 yet, especially since it’s still in
beta.
How does the directory approach work with rspec 1? (And feel free to
point me to a blog post or wiki entry that documents this–I’ve done
some googling but haven’t found anything yet).
Take a peek at
to see how rspec-rails-1.3.2 configures rake tasks to run files in
different directories.
HTH,
David
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.