where should I put the integration tests when using rspec?
There is an integration-folder in test-directory, but if I place tests
here then how can I benefit from the fixtures-dir in spec-folder? I want
to stay in the spec-folder, right? I do not want to maintain two
fixtures. I’m not sure how important it is to stick with the
default-folders that come with rspec and rails. What if I need those
scripts someday.
According to rspec’s documentation they recommend that I stub out the
model when testing controller. For me there is not much value from
testing controllers this way. Controller-code is small, it is often
mostly workflow-code. Also, I thought that part of the whole method of
BDD was to begin with full-integration tests at the outermost level and
that I then perhaps could work my way in to the model with unit tests. I
cannot understand why I should stub out model in controller-tests and
call db in model-tests. Shouldn’t it be the other way round? Drill
through the whole cake from controller-tsts and stub everything else out
from model-tests ?
I would rather delete spec/controller and have something like spec/full
or maybe spec/requirements. That would give me my full-integration tests
and the controller-tests. Are there any problems with this strategy?
On Mon, Oct 20, 2008 at 12:49 PM, Rasmus R. [email protected] wrote:
If you don’t need it today and it’s not being used, delete it. If you
find you need it, well, that’s why use version control.
According to rspec’s documentation they recommend that I stub out the
model when testing controller. For me there is not much value from
testing controllers this way. Controller-code is small, it is often
mostly workflow-code. Also, I thought that part of the whole method of
BDD was to begin with full-integration tests at the outermost level and
that I then perhaps could work my way in to the model with unit tests. I
cannot understand why I should stub out model in controller-tests and
call db in model-tests. Shouldn’t it be the other way round? Drill
through the whole cake from controller-tsts and stub everything else out
from model-tests ?
A controller test is not an integration test. In default Rails testing
(non-rspec) controllers are often tested this way, but in RSpec
controllers are treated as objects that should be tested in isolation.
Stories/features are used to run through the whole stack. Cucumber is
the tool that you’ll want to look into for providing that full-stack
integration testing when using RSpec:
I don’t do that, and I don’t encourage others to do that, but there
are situations where people feel it is valuable, just not me. The fact
that controllers are simple is a great thing. Spec’ing controllers in
isolation puts you in a position to leave controllers simple as the
application grows and changes
I would rather delete spec/controller and have something like spec/full
or maybe spec/requirements. That would give me my full-integration tests
and the controller-tests. Are there any problems with this strategy?
There is a well-defined directory structure for a reason. When writing
Rails apps you get a lot of niceties for free from rspec-rails based
on how the directory structure is laid out. You could come up with
whatever directory you want, but you’ll have to configure and/or tweak
rspec so it gives you the same niceties.
I recommend trying to do things the default rspec way, and then as you
become familiar with it you should start branching out into trying
different ways of doing things, and post back to the mailing list
along the way so you can share. Perhaps some of what you find out will
prove to be helpful to others, or will even lead to changes for the
betterment of writing software using RSpec.
I’m off to catch a plane, hopefully this has helped and not added
further confusion or frustration,
I would rather delete spec/controller and have something like spec/
full
or maybe spec/requirements. That would give me my full-integration
tests
and the controller-tests. Are there any problems with this strategy?
Find the cucumber project on github and you’ll get a /features folder
where you can write your full-stack tests, like rails ‘integration’
tests, or what the XP crowd like to call ‘acceptance tests’.
You can then use the specs in the spec folder to drive out changes to
individual classes, what the XP crowd calls unit testing.
How isolated you make those specs is up to you, but you’ll find most
people on this list will advocate using mocking to isolate
controllers, I certainly do.
cheers,
Matt
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.