On Mon, Oct 20, 2008 at 12:49 PM, Rasmus Rasmussen <[EMAIL PROTECTED]> 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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
