I don’t like fixtures. They are only likely to help in situations where you are running a full suite of tests and will be a hindrance in other situations. Unless you’re creating a lot of objects in your specs, I don’t think fixtures are going to speed them up enough to be worth it.
In unit tests, I try like hell to avoid using FactorGirl all-together. I use <object>.new wherever possible. When testing a scope, I’ll create what I need. I’ll use build_stubbed from FactoryGirl wherever I can – it works great in view specs (which can help limit the number of feature specs you’re writing too!).
Never seen that before. Doesn’t sound like something I’d be interested in, personally.
Read up on the Test Pyramid (Rails version). Try to keep your integration tests few and focused on testing integration, not details. Test details as much as possible in unit tests.
Try to avoid running the same behavior more than once. A common cause of slow tests is over-testing.
Try to avoid the database, file attachments, or external services in the vast majority of your tests.
I still often feel I test the same behaviors more than once, in an example for implement a search functionality page, I start from outside-in, so I create a feature spec with creating few objects in the db, then do a search and asset on the page for the result. When I go to implement in lower levels, then I either create query object or a method in model itself for search functionality, and I create a test for it, so I have to do it again by create few objects in db, then call itself method and assert the result. I feel both tests are almost the same including setup data for test and asserting result, so the only different one is drive from user click the page, and another one is from calling the method directly. What do you think about this context?