Mocking vs. Test DB?

Question

Earlier I asked this question How to correctly unit test my DAL?, one thing left unanswered for me is if to really test my DAL is to have a Test DB, then what is the role of

Answer 1

It's not only the state of the DB you must consider, it's also availability. If your DB is offline why should all of your DAL tests fail?

What you need to test is that your DAL issues the correct commands in order to create / retrieve / update / delete. You don't need to execute SQL for this, you can just use an object persistence framework and check that you give it the correct instructions.

Answer 2

The problem could very well be in the original question. Some of the more popular examples of MVC use a shortcut by returning a DbSet such as:

public class MusicStoreEntities : DbContext
    {
        public DbSet<Album> Albums { get; set; }
        public DbSet<Genre> Genres { get; set; }
        public DbSet<Artist> Artists { get; set; }
        public DbSet<Cart> Carts { get; set; }
        public DbSet<Order> Orders { get; set; }
        public DbSet<OrderDetail> OrderDetails { get; set; }
    }

To me this tightly couples the implementation of persistence which I believe is a bad thing. It woud be better to return List<t> which could easily be mocked.