I often see long before blocks with lots of should_receive ... and_return inside.

Remember that before blocks are about setting up the "stage" (the context of your test), not declaring your expectations!
Also, they get run for every spec (every it block).

So :

• convert your should_receives to stub calls in before blocks;
• have one or more it blocks with should_receive, if you actually care that the calls are made (watch out not to expect calls that are just an implementation details, only things that you need to see ca...

Wether you modify an existing named scope or add a new one, or when you write a new query, make sure you have the proper indices.

This particularly applies if you're going to run non-trivial queries of course (admin backends, analytics, etc).

Compound indices

A chain of scopes results in (usually) one query. You should take into account all attributes (columns) that are used in :conditions, :join, :group, :having, and :order, as all those result in filtering and sorting–slow operations without indices.

Take the list of all ...

File uploads with .png are +10 times slower than using .jpeg or .gif.

# Bad
post :create, {
  :property_id => property.id,
  :photo => {
    :image => File.open("#{Rails.root}/public/images/foo.png")
  }
}

# Good
post :create, {
  :property_id => property.id,
  :photo => {
    :image => File.open("#{Rails.root}/public/images/foo.jpeg")
  }
}

TL;DR: If using :group => :some_field you might want to :order => 'NULL'.

According to the man Archive

By default, MySQL sorts all GROUP BY col1, col2, ... queries as if you specified ORDER BY col1, col2, ... in the query as well. If you include an ORDER BY clause explicitly that contains the same column list, MySQL optimizes it away without any speed penalty, although the sorting still occurs. If a query includes GROUP BY but you want to avoid the overhead of sorting ...

What
The object returned by has_defaults apparently is the same between multiple object creations.
Consider this scenario:

class Order
  has_defaults :items => []
end

o1 = Order.new
o1.items #=>> []
o1.items << item
o1.items #=>> [item]

o2 = Order.new
o2.items #=>> [item]

So, now o2.items is not empty by default because we modified the same object in has_defaults

How
When using has_defaults on a model, consider using it in the following way:

has_defaults :items => proc {[] }

When
Consider do...

wkhtmltopdf hangs on mac during cucumber unless we click on it. The main reason is with the version we use which is 0.11.0_rc1 and in out app/bin we have another version and it is a known issue with these versions. The fix is to go to 0.9.9, to downgrade the version we installed earlier using brew:

* brew uninstall wkhtmltopdf
* brew update
* brew versions wkhtmltopdf
* if you see output like 
*         `0.9.9    git checkout 6e2d550 /usr/local/Library/Formula/wkhtmltopdf.rb`
           then `cd /usr/local`
* g...

1. Add to the end your .bash_profile export PATH="./vendor/bundle/bin:$PATH"
2. Also add alias bi="bundle install --path vendor/bundle --binstubs=vendor/bundle/bin"
3. Then to bundle install next time just use bi

Now no more bundle exec before any rake, cap, spec or anything else :)

When simply checking equality or truthiness then
Instead of:
it "should have role set to admin" do
@user.role.should eql('admin')
end

it "should be valid" do
  @user.valid?.should be_true
end

Do:
it { @user.role.should eql('admin') }
it { @user.valid?.should be_true}

Try to stick to one expectation per test block, diverge in exceptional circumstrances, so instead of:
describe "#some_method" do
before(:each) do
@object = Class.new
end

   it "should have attributes set" do

...

One of the main source of bugs and complexity in the code is when a functional method (that we expect to return a value) return different values under different circumstances.

For example, we ruby programmers have a bad habit of returning nil from a method when certain condition is not fulfilled else return an Array or Hash. That just makes the calling code unnecessary complex and error prone because then it has to do different checks.

Bad Practice:

def bad_method(param)
  return unless param == 'something'
  [1,2,3]
end

...