[rspec-users] ????? lots of Q's about integration tests with rspec

Zach Dennis zach.dennis at gmail.com
Mon Oct 20 13:24:37 EDT 2008


On Mon, Oct 20, 2008 at 12:49 PM, Rasmus Rasmussen <lists at ruby-forum.com> wrote:
> Hello all,
>
> 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.
>

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:
http://github.com/aslakhellesoy/cucumber/wikis

I know there are people who use controller specs are integration-style
tests with RSpec. You'll want to look into "Integration Mode"  if you
are interested in doing that:
http://rspec.rubyforge.org/rspec-rails/1.1.8/classes/Spec/Rails/Example/ControllerExampleGroup.html

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,

-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com


More information about the rspec-users mailing list