Currently, the rspec2 branch of remarkable_activerecord has a modified have_scope that matches against the constructed Arel scopes. This is because everything is scoped, and turned into anonymous functions, and so it is difficult to get original conditions passed to Arel. However, Arel itself keeps track of this. The macros work by taking what you pass and constructing an Arel query from scratch, then comparing it with what was declare.

This works very well, however when it comes to printing it, it is very, very ugly. There is no pretty printer for Arel (and no, awesome_print does not actually pretty-print Arel objects). For the moment, I have expectation messages emit SQL instead. It is better than calling inspect on the Arel object, but not that much better.

This is not a huge priority for me, though it is more important if you are planning to print out specs for clients or using i18n. I'd appreciate some help with this part of the code, if anyone can come up with a good pretty-printer for Arel.

I forked remarkable, updated the Gemfile to use rails 3 RC and everything passes. Very strange why the rubygems package breaks...

Remarkable 3.3:

describe Post do
  subject_attributes { :title => "Post" }
  describe :title => "New Post" do
    it { should do_something }
  end
end

This does not exist in Remarkable 4.0.0.alpha1. Rspec2 has a metadata system that lets you do this:

describe Post, :extra_fields => whatever do
describe "when pending", :pending => true
end

describe "when focused", :focus => true
end

end

So there is some conflict with this system. At the minimum, subject_attributes would have to be implemented through metadata.

I've cut this out from Remarkable::ActiveRecord, but I'm noticing this is the heart of the Remarkable::Rails macros.

So folks, suggestions from people who use these features are definitely welcomed.

Please upvote this if this is important.

I don't generally use Remarkable Rails except as a way to pull in Remarkable ActiveRecord.

Here's what I am thinking:

• Split off Remarkable::Rack for rack middleware and endpoint testing. This include things like the redirect_to macros.
• Split off Remarkable::ActionController for ActionController API compliance. Or something similar to that. This would let you use macros for your own custom controllers, including compliant controllers such as ActiveMailer
• Remarkable::Rails should then end up being a thin layer built on top of all of these different macros.

I'd like some feedback with this. Unlike Remarkable::ActiveRecord, since I don't realy use this, I don't know all the features very well.

(Expanded blog post: http://ruby-lambda.blogspot.com/2010/04/improving-macro-registration-for.html)

Currently, you have to do this:

Remarkable.include_matchers!(Remarkable::ActiveModel, Rspec::Core::ExampleGroup)

But seriously, do the developers need to know they are targetting Rspec::Core::ExampleGroup? So there should be a default.

The other thing is that due to the modularity of Rails 3, it makes sense to have a set of macros built on top of other macros. So for example, ActiveRecord macros are built on top of ActiveModel macros. Not everyone will want to include the entire Rails stack just to use the macros, and we certainly don't want to expose a target (at least, not without having to dig).

Here is a mock API of what I'm thinking of:

The developer adds this:
Remarkable.register_macros(:activemodel, Remarkable::ActiveModel)
Remarkable.register_macros(:activemodel, Remarkable::ActiveModel,
:target => Rspec::Core::ExampleGroup)
Remarkable.register_macros(:activerecord, Remarkable::ActiveRecord,
:depends_on => :activemodel

This makes it easy for plugin developers:

Remarkable.register_macros(:foreigner, Remarkable::Foreigner,
  :depends_on => :activerecord)
Remarkable.register_macros(:paperclip, Remarkable::Paperclip,
  :depends_on => :activerecord)

If you are using only pieces, then you can active the macros:

Remarkable.activate!(:activerecord)
Remarkable.activate!(:paperclip)

Which will idempotently include the macros and its dependencies into Rspec2.

Remarkable::Rails, being the gregarious gem it is, will call

Remarkable.activate!

... which will load up all of the macros. This would be in keeping with the expected convention for Rails while still providing modularity.

Specs currently do not work with Rails 3.1.0

There are also large numbers of Rails 3.1.0 deprecation.

Hello,
Trying out remarkable with rails 3.1 app
my Gemfile
..
gem "rspec"
gem "rspec-rails"
gem "remarkable_activerecord", "~> 4.0.0.alpha4"

spec_helper
..
require 'rspec/rails'
require 'remarkable/active_record'

a model spec
..
it { should
validate_numericality_of(:amount).greater_than_or_equal_to(0) }

Get this error:

Failure/Error: it { should
validate_numericality_of(:amount).greater_than_or_equal_to(0) }
NoMethodError:
undefined method `greater_than_or_equal_to' for

RSpec::Matchers::Matcher:0xfa8e92c

this wonderful soft is due for upgrade :)

It would be great to be able to use remarkable with Rails 3.1 without deprecation warnings, but there's no way to do that right now without forking the gem, due to lack of gemspecs. Either adding gemspecs, or releasing a new version of the gem would resolve this.

[Edit by Hosh: Moved Rails 3.1 without deprecation to a different issue #32]

The remarkable repo has no gemspec file, making it tough to add the repo as the gem source directly into the Gemfile (correct me if I'm wrong pleaes).

I see that the details that go into the gemspec are already in the Rakefile, but it would be better to have a seperate gemspec. Would be useful for those who are using the latest and maybe-greatest code of the repo.

Following code could be used to ensure, that default scope works as expected:

EmailLetter.scoped.to_sql.should == EmailLetter.unscoped.where(:sent => false, :error => false).to_sql

Usage would be:

it { should have_default_scope.where(:sent => false, :error => false) }

I'll provide pull request if needed.

I just upgraded to ruby 1.9.2 and I'm having all kinds of issues with remarkable. I've tried everything. I finally solved them, but I do not think its the right solution. Here's whats been happening:

describe InvoiceItem do
context "validations" do
it { should validate_presence_of(:description) }
end
end

Gives me the following error:
wrong number of arguments (1 for 0)

The fix:

it { InvoiceItem.new.should validate_presence_of(:description) }

Doing:

it { InvoiceItem.should validate_presence_of(:description) }

Gives me the following error:
undefined method `description=' for #Class:0x00000102f324d0

Any idea whats going on here? In 1.9.1 it was all working fine. 1.9.2 I'm getting these strange errors.

Thanks for your help.

Observation: The following succeeds.

describe Foo do
it { should have_and_belong_to :bars, :after_add => :tweet_about_bar }
end

class Foo < ActiveRecord::Base
has_and_belongs_to_many :bars
end

Expectation: It should check for the presence of the after_add callback in the association declaration.

time_table_controller_spec, line 23:

mock_models :post 

Error in console:

/home/petrushka/.bundle/ruby/svn/gems/remarkable-4.0.0.alpha4/lib/remarkable/core/macros.rb:15:in method_missing': undefined methodmock_model' for :Class (NoMethodError)

from /home/petrushka/webdev/my_app/spec/controllers/admin/timetable_controller_spec.rb:23:in `block (2 levels) in <top (required)>

spec_helper: https://gist.github.com/1d92348b08b71a5fc798

ruby 1.9.3dev (2010-05-08 trunk 27674) [x86_64-linux]
spork (0.8.4)
Rails 3: beta3
Rspec2: beta11

this wonderful soft is due for upgrade :)

So some sample Rack macros:

it { should comply_with_rack_api}
it { should redirect_to "/" }
it { should respond_with :404, /We cannot find the page/ }

If the subject_attributes pattern gets implemented cleanly, maybe:

describe :post => "/users/memberships", :json => { :user_id => "foobear" } do
   it { should respond_with valid_rack_response } 
   it { should respond_with :200, :ok }
end

Thought it might end up with something like:

describe RackEndpoint do
  when_receiving :post => "/users/memberships", :json => { :user_id => "foobear" } do
    it { should respond_with valid_rack_response } 
    it { should respond_with :200, :ok }
  end
end

(to avoid having to wrap around describe)

With an extremely simple model and spec:
class User < ActiveRecord::Base
validates_uniqueness_of :username
end

describe User do
should_validate_uniqueness_of :username
end

The following error is produced

Failures:

1. User
   Failure/Error: send(should_or_should_not, send(method, *args, &block))
   ScriptError:
   could not find a User record in the database

   ./spec/models/user_spec.rb:4

   ./spec/models/user_spec.rb:3

EDIT:
Using Rails 3.0.7
rspec 2.5.0
remarkable 4.0.0.alpha4

should_belong_to :whatever
in a spec for a Rails 3.1 app, causes this warning:

DEPRECATION WARNING: primary_key_name is deprecated and will be removed from Rails 3.2 (use foreign_key instead). (called from reflection_foreign_key at .../gems/remarkable_activerecord-4.0.0.alpha4/lib/remarkable/active_record/matchers/association_matcher.rb:97)

Thanks!

have_scope given any options always fails with something like

Failure/Error: it { should have_scope(:ordered).order('name') }
   Expected :ordered when called on User scope to SELECT "users".* FROM "users" ORDER BY name, got SELECT "users".* FROM "users" ORDER BY name

i.e. expected and real SQL queries are the same. This is due to fact that comparison of two similarly created arel objects returns false. I can test this from rails console. Given class

class User < ActiveRecord::Base
  scope :ordered, order('name')
end

from console

real = User.ordered.arel
expected = User.scoped.send(:order, 'name').arel
real == expected #=> false
real.to_sql == expected.to_sql #=> true

Changing options_match? to compare to_sql values fixes problem:

def options_match?
   @options.empty? || @scope_object.arel.to_sql == arel(subject_class, @options.except(:with)).to_sql
end

The scope is: default_scope order('start_at')

The spec is: it { should have_default_scope.order('start_at') }

I get the below error with & without the order method tacked on to the matcher. Also, I noticed that the spec is for 2.3.3 only so maybe this functionality isn't available yet in 3.0.

The relevant portion of the stack trace is:

/Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/activerecord-3.0.0.beta4/lib/active_record/relation.rb:331:in []': Symbol as array index (TypeError) from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/activerecord-3.0.0.beta4/lib/active_record/relation.rb:331:insend'
from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/activerecord-3.0.0.beta4/lib/active_record/relation.rb:331:in method_missing' from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/remarkable_activerecord-4.0.0.alpha4/lib/remarkable/active_record/matchers/have_default_scope_matcher.rb:19:indefault_scope'
from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/remarkable_activerecord-4.0.0.alpha4/lib/remarkable/active_record/matchers/have_default_scope_matcher.rb:19:in map!' from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/remarkable_activerecord-4.0.0.alpha4/lib/remarkable/active_record/matchers/have_default_scope_matcher.rb:19:indefault_scope'
from /Users/natekidwell/.rvm/gems/ruby-1.8.7-p174@thefannypack/gems/remarkable_activerecord-4.0.0.alpha4/lib/remarkable/active_record/matchers/have_default_scope_matcher.rb:26:in `interpolation_options'

Specs currently do not pass 3.0.10

Some version bump would really be nice, there are many tickets about ralis deprecation warning which was merged to master some time ago. For rails 3.2 this makes one unable to use remarkable at all, and because of repo organization one cannot just simply provide git url with branch name :/