Re: [rspec-users] Merb
On 20.10.2008, at 22.05, Ashley Moran wrote: There is an API for this though[2], and it was deprecated as of RC1, but has now apparently been reintroduced. Lawrence Pit on the merb list explains the syntax: # Example # dispatch_to(MyController, :create, :name = 'Homer' ) do |controller| # controller.stub!(:current_user).and_return(@user) # end Yeah, I was using that API to a great extent with a recent project and was pretty successful at doing outside-in development with rspec and merb. The syntax used in merb controller specs is a bit different from what Rails uses, but once you got around it, it was actually pretty cool and flexible. Here's a snippet from a controller spec in the project: http://pastie.org/private/6uijgfwwzjngvhbkgxwqq Note that I generally stub both render and display for the controller to make the tests run faster. There's probably a lot of optimization left to do with the specs but I find the dispatch helpers pretty cool for building more specialized methods such as do_post. I hope the merb folks will keep us outside-(s)inners in mind and not scrap the API. Cheers, //jarkko -- Jarkko Laine http://jlaine.net http://dotherightthing.com http://odesign.fi Check out my latest book, Unobtrusive Prototype, fresh off the Peepcode oven: http://peepcode.com/products/unobtrusive-prototype-js ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Dreading Controller Specs
On 21 Oct 2008, at 10:45, Rob Lacey wrote: I almost am tempted to simplify the controller by using only the User model and moving most of the checks out of the controller action entirely and putting all into User, although that would mean that the user model, single_sign_on and music_service would then be really tightly coupled which wouldn't be great either. I The Rails Way (assuming you are using Rails) is to make your controllers do virtually nothing - find/create an object, call a method on it, decide which view to render and that's it. So, actually what you suggest would be best. However, rather than talking to your models directly, the controller could talk to a presenter object, which does the glue work (finding the associated models, calling the relevant methods in the correct order and packaging up the results) - you can then RSpec your presenter in the same way as you would a model. This makes your controller specs (and implementations) trivial: it should find a single sign-on do @presenter = mock 'SingleSignOnPresenter' @presenter.should_receive(:request_token).with(secret, email_address).and_return(:whatever) post :request_token, :secret = 'secret', :email_address = '[EMAIL PROTECTED] ' response.should redirect_to(some_path) end I actually use helpers (given_a_single_sign_on_presenter and expect_to_request_a_token) instead of setting up the mocks and expectations within the spec, just to make it a bit more readable. Then you can RSpec your SingleSignOnPresenter separately, in much the same way as you would spec a model, and keep the associations (and implementation details) away from your controller. Baz. Rahoul Baruah Web design and development: http://www.3hv.co.uk/ Nottingham Forest: http://www.eighteensixtyfive.co.uk/ Serious Rails Hosting: http://www.brightbox.co.uk/ Lifecast: http://www.madeofstone.net/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocks: expectations vs spying
On Mon, Oct 20, 2008 at 2:03 AM, Matt Wynne [EMAIL PROTECTED] wrote: On 19 Oct 2008, at 21:18, Ashley Moran wrote: On Oct 19, 2008, at 9:32 am, Matt Wynne wrote: [1] http://notahat.com/not_a_mock Looks sweet - it will be in my first mock on Monday! Thinking about it - how do you use multiple mocking frameworks in a given project? Is it safe to re-open a Spec::Runner.configure do |config| block at the top of an individual spec after I've loaded spec_helper (which will have to be configured to use the default rspec mocking that 90% of the project uses)? Not really. The problem is that examples are stored for evaluation later, whereas the configuration is evaluated right away. The reason rspec won't support using multiple mock frameworks is rspec mocks and mocha both extend Object (to support mock behaviour on real objects) and they use the same methods to create instances of mocks. I think that if we wanted to support multiple mock frameworks, all of the frameworks would have to offer an explicit mode where you could extend objects to behave like mocks but would have to do so explicitly for each object. Flexmock already works this way. FWIW, David cheers, Matt ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocks: expectations vs spying
So if I want to have a spec suite which uses a combination of mocking frameworks, is this possible? Maybe if some of the files include ../not_a_mock_spec_helper and the others include ../default_spec_helper and then both those files require some common spec_helper file? On 21 Oct 2008, at 14:47, David Chelimsky wrote: On Mon, Oct 20, 2008 at 2:03 AM, Matt Wynne [EMAIL PROTECTED] wrote: On 19 Oct 2008, at 21:18, Ashley Moran wrote: On Oct 19, 2008, at 9:32 am, Matt Wynne wrote: [1] http://notahat.com/not_a_mock Looks sweet - it will be in my first mock on Monday! Thinking about it - how do you use multiple mocking frameworks in a given project? Is it safe to re-open a Spec::Runner.configure do |config| block at the top of an individual spec after I've loaded spec_helper (which will have to be configured to use the default rspec mocking that 90% of the project uses)? Not really. The problem is that examples are stored for evaluation later, whereas the configuration is evaluated right away. The reason rspec won't support using multiple mock frameworks is rspec mocks and mocha both extend Object (to support mock behaviour on real objects) and they use the same methods to create instances of mocks. I think that if we wanted to support multiple mock frameworks, all of the frameworks would have to offer an explicit mode where you could extend objects to behave like mocks but would have to do so explicitly for each object. Flexmock already works this way. FWIW, David cheers, Matt ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Dreading Controller Specs
On 21 Oct 2008, at 13:08, Rahoul Baruah wrote: On 21 Oct 2008, at 10:45, Rob Lacey wrote: I almost am tempted to simplify the controller by using only the User model and moving most of the checks out of the controller action entirely and putting all into User, although that would mean that the user model, single_sign_on and music_service would then be really tightly coupled which wouldn't be great either. I Then you can RSpec your SingleSignOnPresenter separately, in much the same way as you would spec a model, and keep the associations (and implementation details) away from your controller. Doesn't this just end up shifting the ugly mocking code into the Presenter specs though? The stock answer to this question is to move this logic down into the model layer, so that the interface the Presenter / Controller uses to work with the database is simpler. This is what people call 'listening to your tests' - if it's hard to mock, it's probably indicative of a problem in your design. However, I worry about this 'skinny controller, fat model' advice, it still doesn't feel like the final answer. To me, ActiveRecord classes already have too many responsibilities, without making them also orchestrate calls to other models. I have been thinking about this a lot lately, and I am starting to feel like I also need a Service layer between the Controller / Presenters and the 'Data Access Layer' (Models) to orchestrate the work. cheers, Matt ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Mocks: expectations vs spying
On Tue, Oct 21, 2008 at 10:41 AM, Matt Wynne [EMAIL PROTECTED] wrote: So if I want to have a spec suite which uses a combination of mocking frameworks, is this possible? Maybe if some of the files include ../not_a_mock_spec_helper and the others include ../default_spec_helper and then both those files require some common spec_helper file? That could work - but the conflict I described is a process-wide conflict - so you'd need to run the examples in those dirs w/ separate rake tasks to really eliminate the conflict. On 21 Oct 2008, at 14:47, David Chelimsky wrote: On Mon, Oct 20, 2008 at 2:03 AM, Matt Wynne [EMAIL PROTECTED] wrote: On 19 Oct 2008, at 21:18, Ashley Moran wrote: On Oct 19, 2008, at 9:32 am, Matt Wynne wrote: [1] http://notahat.com/not_a_mock Looks sweet - it will be in my first mock on Monday! Thinking about it - how do you use multiple mocking frameworks in a given project? Is it safe to re-open a Spec::Runner.configure do |config| block at the top of an individual spec after I've loaded spec_helper (which will have to be configured to use the default rspec mocking that 90% of the project uses)? Not really. The problem is that examples are stored for evaluation later, whereas the configuration is evaluated right away. The reason rspec won't support using multiple mock frameworks is rspec mocks and mocha both extend Object (to support mock behaviour on real objects) and they use the same methods to create instances of mocks. I think that if we wanted to support multiple mock frameworks, all of the frameworks would have to offer an explicit mode where you could extend objects to behave like mocks but would have to do so explicitly for each object. Flexmock already works this way. FWIW, David cheers, Matt ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Dreading Controller Specs
On Tue, Oct 21, 2008 at 5:45 AM, Rob Lacey [EMAIL PROTECTED] wrote: However, I seem to dread spec-ing out controllers, they end up being quite untidy, I think maybe I am approaching them in the wrong way as it probably shouldn't be as hard as I am making it. For what it's worth, Rob, I'm totally with you. The generated code for controller specs has always felt...well, wrong to me. And it's been a frustration every time I've sat down to try to write new controller specs the same way, taking many times longer than it takes to write the controller. The bad part has been the work required to set up the stubs and mocks -- for just the reason you cite. Conforming to the single expectation per test pattern means I have to figure out and stub every method that gets called and make it return a reasonable value, and then I have to *mock* each call at least once to confirm that it gets called. By this point I've essentially written the model interface twice, which feels like extraordinary extra work -- and it also feels brittle. Reasonable changes in the model require unreasonable maintenance in the controller stubs and mocks. The only reason for all of this work is the principle of code isolation. You're supposed to make sure you're only running the code in the unit you're testing -- but because controllers sit at the heart of your app, *of course* they're going to have a great deal of interaction with everything else. That isn't wrong and it doesn't necessarily make the controllers too fat. But it makes the testing fat. Just stubbing the relationship between model collections and objects is complex. It also looks screwy -- and it isn't really a test of the controller. But it has to be done if you're not going to talk to the model. There are some cheats, of course. You can make blanket responses to stuff you don't feel like mocking. The null_object option to RSpec mocks is such a cheat; so's stub_everything in Mocha. But to me they feel like copouts, and they return null by default, which is most often the wrong behavior, so they don't save work. Mock_model and stub_model are intended for views, and stub_model doesn't isolate you from the model. There are some extension plugins that do some of the mocking/stubbing grunt work for you, but that reduces transparency and they don't know about anything but the most common 'formula' methods. The conclusion I'm starting to reach is that it often isn't worth it. All these hours of work to avoid talking with actual models... But if you just plain used the models, so what? Yes, your controller specs could fail if your model is buggy or unimplemented. But if your model's properly spec'ed you'll get failures on the bug there too, pinning the problem down, and the implementation constraint simply means you can't write models *last*. You'd implement methods on them before or simultaneous with the controllers that call them. That's not a bad order of things. So now I'm experimenting with live models. I'm using simple, basic factory methods (I use fixture_replacement2) to create objects for my controller specs to operate on, saved or unsaved as necessary, and using Mocha to inject expectations into the actual objects for specific examples. I may look at not_a_mock for that, too, now that it's being talked about here. This may not be as philosophically pristine as total isolation, but it's simpler and cleaner. You don't have to replicate fake model complexity it in the controller spec. Most of the lines in the controller spec are once again about the _controller,_ not about setting up models. It's also slower, but only a bit. Even with autospec, waiting on my tests to begin is already slow enough that I don't feel it makes a huge difference. I'm documenting my approach, too, and what I've been thinking and learning about RSpec from a thoughtful beginner perspective, and hope to have something I can post on that soon. (That documentation is, in fact, one of the motivations for my current project.) That's my take. It's working for me so far, but with the caveat that I haven't carried a project through to completion with this approach. If any of the _cognoscenti_ can offer reasons why this is a horribly bad idea that'll blow up in my face sooner or later, I'm open to being convinced. I also offer my apologies if this is a topic that comes up on this list over and over again, and if my little rant here is a common and tired one. -- Have Fun, Steve Eley ([EMAIL PROTECTED]) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] config.gem/rspec-rails/rspec bug (#577)
Hey all, Just a heads up about a bug related to configuring the rspec gems in your rails 2.1.1 projects: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/577 Apparently, if you config.gem both rspec and rspec-rails 1.1.9 w/ rspec first, you'll get an error: # DON'T DO THIS: config.gem 'rspec', :lib = 'spec', :version = '1.1.9' config.gem 'rspec-rails', :lib = 'spec/rails', :version = '1.1.9' The workaround is to either reverse these lines: # OK config.gem 'rspec-rails', :lib = 'spec/rails', :version = '1.1.9' config.gem 'rspec', :lib = 'spec', :version = '1.1.9' or just require rspec-rails if you're using rubygems = 1.2 (since installing rspec-rails will, by default, install rspec) # OK config.gem 'rspec-rails', :lib = 'spec/rails', :version = '1.1.9' Keep your eye on the ticket (http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/577) to see when this is resolved. Cheers, David ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Dreading Controller Specs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21 Oct 2008, at 16:51, Matt Wynne wrote: Doesn't this just end up shifting the ugly mocking code into the Presenter specs though? The stock answer to this question is to move this logic down into the model layer, so that the interface the Presenter / Controller uses to work with the database is simpler. This is what people call 'listening to your tests' - if it's hard to mock, it's probably indicative of a problem in your design. However, I worry about this 'skinny controller, fat model' advice, it still doesn't feel like the final answer. To me, ActiveRecord classes already have too many responsibilities, without making them also orchestrate calls to other models. I have been thinking about this a lot lately, and I am starting to feel like I also need a Service layer between the Controller / Presenters and the 'Data Access Layer' (Models) to orchestrate the work. Personally I dislike the name Presenter - and much prefer Service, Builder or Adapter depending upon what its doing; everyone else seems to call it a presenter however. But the point of the Presenter/Service/Whatever is precisely so that neither the controller nor the models have to orchestrate the calls between associated models. If you think of it that way then I think it deals with your points above: * the presenter/service's role is to coordinate the models - so its specs are purely about mocking the associations and the calls inbetween them * the presenter/service isn't a model (not ActiveRecord::Base) - so it's not adding extra responsibilities to the models * it is pretty much a service layer sat between controllers and models Rahoul Baruah Web design and development: http://www.3hv.co.uk/ Nottingham Forest: http://www.eighteensixtyfive.co.uk/ Serious Rails Hosting: http://www.brightbox.co.uk/ Lifecast: http://www.madeofstone.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkj+NDoACgkQu0BNRvjN8xRIsQCfQMkAVClEQOqPmdF9dPDm8Afq o1sAnRF5gYkDI1qgfM8G2S+PpdLOUHaz =fIkf -END PGP SIGNATURE- ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Dreading Controller Specs
On Tue, Oct 21, 2008 at 3:57 PM, Rahoul Baruah [EMAIL PROTECTED] wrote: * the presenter/service's role is to coordinate the models - so its specs are purely about mocking the associations and the calls inbetween them * the presenter/service isn't a model (not ActiveRecord::Base) - so it's not adding extra responsibilities to the models * it is pretty much a service layer sat between controllers and models There seems to be some overload on the word Presenter in Railsspeak. As best I can tell, people are using it to refer to two or more totally different patterns. Initially I thought presenters were for encapsulating limited-domain *controller and view logic* in such a way that they could be embedded in other controllers, thus allowing composition in views. Things like sidebar widgets, or components of a dashboard, or a reusable address box, etc. Stuff that benefits from maintaining its own data so you can't just a partial, but it's still more about the view than the model. On Googling this post, however, I've found that some people do use it that way, but other people talk about the Presenter pattern as a class to aggregate data before sending it to (or split data after receiving it from) the controller. I.e., what you're saying. I think Jay Fields confused the issue by talking about presenters in this way, but saying you're doing it for the sake of the *view.* All of this has convinced me that the name Presenter sucks and nobody should use it. My thinking this is unlikely to change anything, but at least people ought to agree on what they are. What you're talking about, Rahoul, at least one or two people are calling a Conductor: http://blog.new-bamboo.co.uk/2007/8/31/presenters-conductors-on-rails Personally I prefer handling it in the model, and letting models act as compositions of other models if need be, but that's just me. -- Have Fun, Steve Eley ([EMAIL PROTECTED]) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Cucumber, more examples, tabular data input sets
Matt Wynne wrote: ScenarioTemplate: Non admins are rejected Given I login as Joe without the '[privilege]' privilege When I [request_method] /admin[path] Then I am notified that access was denied | privilege | request_method | path | | Joe | GET | /admin | | Joe | POST | /invoces/1 | etc. WDYT? cheers, Matt This sounds like a good direction Matt. I think its important to make it clear that it is not a normal scenario to avoid step matching confusion/why is this not being run. Would you mind creating a ticket for it in lighthouse please? Thanks, -- Joseph Wilk http://www.joesniff.co.uk ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Where is current_user?
Thanks David, Your method works well and rspec succeeds now. Is the preferred way of using code with rspec to not rely on instance variables set in a parent during execution but to rely on the method only construct to be able to interact? I see the way this works for the outline you provided. I am wondering what the implications are with respect to writing ruby code with the assumption parent instance variables will be inherited by children. The approach you are providing would indicate that an attr_read method is preferred so that the retrieve method can be stubbed since the instance variable doesn't get set when tested. Is this a general rule of practice with rspec? As a beginner I'm trying to get the larger picture here and appreciate your insight with this. HR -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
