Prefer tests where all its 4 steps (setup/exercise/verfication/teardown) are clearly identifiable - This helps make tests easy to understand.  
Avoid the use of let/let!/before - The use of these Rspec constructs over nested describe/context blocks tends to spread the multiple steps of testing over different blocks which makes what is happening in these steps harder to understand. 
Use Rspec contexts as a way to show that blocks of code are related - Avoid using context blocks as a way to remove incidental duplicaton between blocks. Use contexts so that their description shows how blocks of code are related. Contexts should be used as a way to group high level concepts together. This is a corollary of the guideline above. 
Don't test private methods - Private method tests create unnecessary coupling between the tests and the implementation details of an object and they break encapsulation. Testing private methods is an additional barrier to refactoring (because tests also have to be changed even if the object's API and behaviour is kept the same). Testing private methods is unnecessary because their behaviour is covered by public methods.   
Remember that the purpose of tests is to catch regressions, provide documentation, and reduce costs (i.e. time and money) and help with application design - When in doubt remember this.  
Don't stub the system under test (SUT) - If an object is so complicated that there is a need to stub it in order to test it then that should be used as a guide to change the design. Also stubbing the sytem under test kind of violates the encapsulation of that object.  A reasonable exception to this are cases in which one cannot change the SUT (e.g. framework code, or legacy code) 
Remember that tests are a tradeoff of confidence, coverage and speed - The tradeoffs one does depend largely on the context. This impacts in which layer to test (i.e. unit, integration), what to test (e.g. sad path, happy path), which tools to use (e.g. database, mocks, real objects, fakes)    
Only load ActiveRecord/Rails for tests that require it - loading Rails takes significant time when running tests. Fast tests are good.
active_record_helperare your friends.  
FactoryGirl.create(:model)(in this order) - not all tests need persisted data. not all tests need to hit the database. tests that don't hit the database are faster.  
Specify a single behaviour in each example - this constrasts with the common advice of using only one assertion per example in Rspec. Multiple expectations might imply a single behaviour. 
Always pass attributes to FactoryGirl which are relevant to the test - this gives needed information to the person reading the test regarding the causes on which it depends. Specifying everything in the factory leads to the same issues that fixtures have and FactoryGirl attempts to avoid.  
What to test: Incoming messages should be tested for their return values; Outgoing messages that have side effects should be tested to ensure they get sent; Outgoing messages without side effects should not be tested.  
In unit tests, units are not classes - A test is a unit if it runs fast and if it is easy to localize the source of test failures, therefore a unit might be a representation of multiple classes collaborating.   
Use tests as a way to define proper contracts and boundaries between components   
Use FactoryGirl's traits 
Prefer using Rspec for integration tests rather than Cucumber 
Prefer spies over mocks in Rspec 
Mock roles not types  
Don't mock types you don't own  
Keep controller tests simple 
-  Testing Rails - a book that contains a nice introduction to testing on Rails by thoughbot.
-  Four-phase test - introduction to the four phases of testing.
-  Let's not - a discussion on the issues of overusing certain RSpec features.
-  Fragile tests - description of the fragile test anti pattern.
-  Testing private methods - discussion around why testing private methods is not recommended and how to deal with it.
-  Practical Object Oriented Design in Ruby
- This is book is a must read if you program in Ruby or in any OO language. There is a great chapter (i.e. chapter 9) on testing.
-  Don't stub the system under test -
-  Working effectively with legacy code
- A compilation of recipes to introduce tests in legacy codebases. This was a hard read for me.
-  Rails Test Types and the Testing Pyramid
-  RSpec rails default helper files
- Announcement of two helpers, rails_helper and spec_helper in order to have a way to not load Rails in some tests.
-  Fast Rails Tests - Corey Haines talk on fast tests
-  Speeding Up ActiveRecord Tests - Corey Haines bog post in which he introduces an active_record_helper
-  Speed Up Tests by Selectively Avoiding Factory Girl
-  Use Factory Girl's build_stubbed for a Faster Test Suite
-  Single expectation test discussion
-  Rails Testing Antipatterns: Fixtures and Factories
-  The magic tricks of testing - a great talk on testing by Sandi Metz. Some of the things she covers are explained in her book 
-  RR 186 with Corey Haines
- it has some great gems on Rails, architecture and gems.
-  Unit tests vs class tests
-  [Units are Not Classes: Improving Unit Testing By Removing Artificial Boundaries]
-  Mocks and explicit contracts
-  xUnit Test Patterns: Refactoring Test Code
- Most resources that talk about anti patterns in tests end up referring to this book. I heard great things of it, but I haven't read it yet.
-  XUnit Test Patterns wiki - the wiki of the book  which contains some of the content described in the book. It is a great resource.
-  Mocks Aren't Stubs - A great article by Martin Fowler in which he explains the difference between mocks and stubs. He also explains the differences in the classical and mockist approach to testing.
-  Refactoring legacy code with tests
-  How to Stop Hating your Test Suite by Justin Searls
-  Fake Object - A description of the fake object pattern
-  Faking APIs in Development and Staging
-  Remove Duplication with FactoryGirl's Traits
-  BDDon’t
-  A Closer Look at Test Spies
-  Thoughts on the symmetry between good test names and your object's API
-  Better Mocking in Ruby
-  Best Practices: Testing Rails controllers with RSpec
-  Upcase's resources on testing - Upcase's resources on testing are really good.