search for: it_should_behave_like

I''m trying to use it_should_behave_like, and something seems to be wonky with the syntax. When I add :shared=>true, the DSL complains that the next line is the fixture declaration: /vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing'': undefined method `fixtures'' for #<Spec::DSL::EvalModul...

I have a lot of controllers with virtually identical functionality for most actions. I''ve been using shared behaviours to DRY things up a bit, but I still have to create separate behaviours for each context before I can use the shared behaviours what I have now is a generic file which contains all the behaviours and examples common to all the controllers, and that file gets loaded from

hi, i want to make a behavior shared between models, the examples need to create new instances etc. Is there a way to pass the model class to the shared behavior? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20071218/5b400cc5/attachment-0001.html

..." # or maybe before(:all) do @feline = described_class.new(:name => "fluffy", :breed => "Siberian") end it "should have long hair" do @feline.should be_long_haired end end describe SiberianCat, "(a subclass of, say, Cat)" do it_should_behave_like "Siberian feline" it "should purr" do @feline.sound.should == "purr" end end describe SiberianTiger, "(a subclass of BigCat)" do it_should_behave_like "Siberian feline" it "should roar" do @feline.sound.should == "r...

...t the described class in my shared behaviour. I''m sure an example will say it better than my words describe "my shared", :shared => true do it "should tell me what the class is its describing" do how_do_i_get_the_user_class_here end end describe User do it_should_behave_like "my shared" #... end So in my shared behaviour, how do I get access to the User class? Cheers Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20071122/3036e7c6/attachment-0001.html

I''m trying to write some tests for the ApplicationController as shared tests that can be run in all of my other controller tests, but am getting a nil.rewrite error. Below is what I have... describe AccountController do it_should_behave_like ''Application controller'' end describe ''Application controller'', :shared => true do it ''should fail require_login check if not logged in'' do User.current = nil controller.require_login.should be_false response.should redire...

Hello, Has anyone already come up with a set of shared behaviours that someone could leverage when adhering to a CRUD concept, with respect to controllers? Relatedly, it would be nice if there were a way to share generalized behaviour specs. -Chris

The Rails ApplicationController (app/controllers/application.rb) serves as an abstract superclass for all other controllers in a Rails application and is a good place to put methods and filters which you want all of your controllers to use. In my case I''m using it to provide methods such as "current_user" and "logged_in?" etc. By default, RSpec

...9;'foo'' ... it ''bar'' ... end describe ApplicationController, "some other facet", :shared => true do it ''abc'' ... it ''xyz'' ... end describe ApplicationController, :shared => true do it_should_behave_like ''ApplicationController one facet'' it_should_behave_like ''ApplicationController some other facet'' end And corresponding ApplicationController subclass specs: describe OtherController do it_should_behave_like ''ApplicationController'...

Hi I just wondered if there was a reason why Rails controller specs are not shareable? eg describe "All XHR POSTs to /gap/calculate_quote", :shared => true do controller_name :gap # ... end describe "XHR POST /gap/calculate_quote with valid details" do it_should_behave_like "All XHR POSTs to /gap/calculate_quote" # ... end blows up with the following error: ########## /Users/ashleymoran/Documents/Development/YourMoney/trunk/src/vendor/ plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing'': undefined method `controller_name...

Hi folks, Can anyone share some accumulated wisdom about the best way to spec mixins in general, and (Jamis Buck-style) ActiveRecord "concerns" in particular? The standard situation here is that there''s a bunch of functionality, related by concept if not by implementation, that one wants to inherit in many different classes (e.g. ActiveRecord models) without having to

...like something that should be fixed. To reproduce, create the following files: a_spec.rb --------- describe "shared", :shared => true do it "should do something" do end end b_spec.rb --------- require ''a_spec'' describe "not shared" do it_should_behave_like "shared" end Now, try it out: % spec b_spec.rb . Finished in 0.018853 seconds 1 example, 0 failures % spec *_spec.rb /usr/local/lib/ruby/gems/1.8/gems/rspec-0.9.3/lib/spec/dsl/ behaviour.rb:9:in `add_shared_behaviour'': Shared Behaviour ''shared'' already ex...

I am writing some specs related to permissions for different kinds of users. Every user has some common examples to test in many different specs. For example, all users can view, and edit their profile. Also, all users can view their own "history." So I have two spec files, say profile_controller_spec and history_controller_spec. They might look like http://gist.github.com/336898

Hi, Is there or could there be any way to test that a method calls "super"? Thanks -- Jonathan Leighton, Web Developer http://jonathanleighton.com/

...bout the right classes, the right routes, the right instance variable. *Furthermore* furthermore, controllers occasionally deviate from the standard RESTful template in a variety of ways, so it''d be nice to be able to "override" the appropriate bits after declaring that it_should_behave_like "ARestfulController" (or whatever). I fear the solution to my requirements is ultimately on par with implementing some kind of make_resourceful-for-specs plugin, which is way beyond what I''ve got time to do at the moment, but I still feel there''s plenty of room fo...

I''m working on a series going over the source code for rspec, and I ran into something interesting with ExampleGroup and SharedExampleGroup. I was wondering if anyone could shed light on it. [NOTE: I''m working through the code for my own edification in learning Ruby. Ruby has some features that I think are incredibly cool, so I''m using a concrete implementation (RSpec)

Hello, I''m playing around with Rspec again after going from test/unit to rspec then back to test/unit... :) Right off the bat, I find myself wanting to do something like this: https://gist.github.com/1128091 Basically, I want to name a context, then call it later by name, passing a block to it. Or in other words... what is the best way to DRY this code?

Hey guys and gals, I have a snippet of code: Net::SMTP(@host, @port, @from_domain) do |smtp| @emails.each do |email| begin smtp.send_message email.encoded, email.from, email.destinations @emails_sent += 1 rescue Exception => e # blah end end end What I want to do is: Say there are 4 emails. First email is sent OK On the second email smtp raises a IOError

Hi I''ve spec''d a class and they pass. Now I''d like to assure that any subclass of this class also passes the same specs. Any suggestions for a clever way to handle this? I''d prefer to keep the existing specs as is (eg instead of moving everything into shared behaviors, or doing something to all the ''describe'' lines) thanks linoj

Is there anyway to achieve inheritance of specifications? Suppose I had an action like def index filter = params[:filter] ? params[:filter] : ''%'' order = params[:order] ? params[:order] : ''created_at DESC'' @posts = Post.find(:conditions => "title LIKE #{filter}", :order => order) ... end Now I might have half a dozen specs for this