similar to: using #include in shared behaviours

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

Given the following ApplicationController specs: describe ApplicationController, "one facet", :shared => true do it ''foo'' ... it ''bar'' ... end describe ApplicationController, "some other facet", :shared => true do it ''abc'' ... it ''xyz'' ... end describe

Hi, I''m developing a RESTful Rails application whose code and specs are becoming increasingly repetitive: every controller does pretty much the same set of things (give or take the occasional twiddle), for example, and so every controller spec is almost identical modulo some names, constants and strings. The make_resourceful plugin, which autogenerates the boilerplate REST

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

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

Hi, I want to be able to get at 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

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::EvalModule:0x324a2cc> (NoMethodError) Here''s the

Is it possible to access the described class in a shared behavior? I''m trying to do something like this: describe "Siberian feline", :shared => true do described_class_instance_as :feline, :name => "fluffy", :breed => "Siberian" # or maybe before(:all) do @feline = described_class.new(:name => "fluffy", :breed =>

Hello All, I''ve just upgraded to rspec/rspec_on_rails 0.9.3 and am very excited about shared descriptions. They couldn''t have come at a better time: I just finished refactoring some REST controllers so that the bulk of the actions are inherited from a superclass. Now I can write the specs once, too. :) I''ve hit a couple of snags, though. I thought I''d

I want to extract the method for logging in so that I don''t have to include it in each before call. Is it bad to use a describe block within the rspec_helper in a rails project for controller tests? I have in my spec_helper.rb describe "an authenticated request", :shared => true do before( :each ) do @u = mock_model( User ) mock_login( @u ) end def

Is there a way I can write something like a shared behaviour for all views that just checks the page responds with a 200 status and has a title, meta tags, and an h1? Here''s an idea for a shared behaviour (that only applies if I set views to use it manually with it_should_behave_like "a standard layout"): describe "a standard layout", :shared => true do

I''m developing a library called Hark. The structure is: lib/ hark/ session.rb mixins.rb hark.rb hark.rb: ==== module Hark include Hark::Mixins ... end application.rb: ==== class ApplicationController < ActionController::Base include Hark end my_controller.rb: ==== def login hs = session[:hark_session] = Hark::Session.new ... end So application.rb

So, here''s the problem: @import isn''t liking other directories. Example: app/ assets/ stylesheets/ extras/ _mixins.sass _variables.sass photographs/ index.css.sass And the contents of app/assets/stylesheets/photographs/index.css.sass is: @import "../extras/mixins", "../extras/variables" I get the following

i keep getting this AssociationTypeMismatch error. i think this could be a bug related to ruby/rails when using mixins. heres a short version of my code: # user.rb require ''friend_invitation'' require ''friendship'' class User < ActiveRecord::Base include FriendInvitationUser, FriendshipUser ... end # friendship.rb ... module FriendshipUser def

Hello, I have the following output when changing form Active Record 1.0.1 to ActiveRecord 1.6: [error] C:/dev/ruby/lib/ruby/gems/1.8/gems/actionpack-1.4.0/lib/action_controller/support/dependencies.rb:24:in `depend_on'': uninitialized constant ActiveRecord::Mixins (ScriptError)\r [error] \tfrom

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

i am currently digging into the rails 2.2.2 source to get a deeper understanding of some features (in particular model-validation) and a better overall insight. most of rails features are encapsulated in a separate module - as far as can see - and wired together through mixins. this makes sense and following the logic in the single modules is easy. but i am getting stuck while puzzling to see it

All, I whipped up a small extension for Prototype to solve some modeling issues I was having on a large JS project. I know there have been serveral alternative "write JS in Ruby" type efforts, including ruby.js, rb2js, and prototype.js itself, but I was hoping to keep it as light as possible while gaining the most powerful aspects of derivation/mixins/callbacks. Much like the prototype

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 All, = What''s New This is a bug fix release. Jamey Cribbs (author of KirbyBase) has run through Active Web Development with Rails, building the Depot sample app on top of Akbar/KirbyBase. A few issues uncovered there were fixed / enhanced in this release. See the CHANGELOG for full details. You can read all about his exercise, starting at