rspec users - Oct 2008 - ????? lots of Q''s about integration tests with rspec

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.

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?

Thanks for advice!

/Rasmus
-- 
Posted via http://www.ruby-forum.com/.

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

On 20 Oct 2008, at 17:49, Rasmus Rasmussen wrote:
> 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