With respect to the point that you'd prefer to use FactoryGirl in lieu of the UI for constructing a depended-on item, I have this thought:

If I had my druthers (and I usually don't), I prefer integration tests that are as black-box as possible. My ideal end-to-end test should continue working even if the implementation changes significantly (that is to say, someone swaps out my Rails backend for Django). It sounds fantastical to some people when I propose this, but it tends to work in more situations than folks presume (though setup is admittedly always more expensive).

In fact, in my adventures as an ATDD consultant, it seems like Ruby community is distinct for presuming that an end-to-end test should be able to access the internal objects. I'd prefer the end-to-end test to run in an entirely different process when I can swing it.

I comment on the difference between the two at length [here](http://searls.testdouble.com/2012/04/01/types-of-tests/#remote-full-stack-application-tests) and [here](http://searls.testdouble.com/2012/04/01/types-of-tests/#local-full-stack-application-tests)