I hate tests that rely upon the database. Slow running tests often enough are never run.
I don't know if you've done the same, but where we could, we used a repository pattern so the business logic wouldn't depend on the EF context directly, and the repository(/ies) the logic relied upon only exposed the minimum needed for that particular piece of code. For example, if the logic only needed to work with the "Bars" table as data, we passed it an IBarRepository* or, often enough, an IRepository<Bar>**. (For logic that required access to multiple tables, we'd bundle together repositories into a unit of work interface.) This allowed us to write unit tests for the business logic and reserve the slower integration tests for the concrete repository classes that were tested independently of any business logic tests.
Of course, that project ended up going off the rails at some point. Large banks, small budgets, what are you going to do.
-----
**IRepository<T> got you CRUD methods "for free" when the concrete Repository<T> class was used. Similarly, substitution for unit tests was also "free" with a StubRepository<T> instance.
*I{T}Repository implementations were reserved for when the free methods above were not required or were insufficient (such as needing specialized queries), as the case may be. These repositories might inherit from the above or go their own different direction, depending upon need.