Currently, our unit tests are using the approach from this link: http://ift.tt/1xKa9UE to mock the Dbcontext.
var data = new List<Blog>
{
new Blog { Name = "BBB" },
new Blog { Name = "ZZZ" },
new Blog { Name = "AAA" },
}.AsQueryable();
var mockSet = new Mock<DbSet<Blog>>();
mockSet.As<IQueryable<Blog>>().Setup(m => m.Provider).Returns(data.Provider);
mockSet.As<IQueryable<Blog>>().Setup(m => m.Expression).Returns(data.Expression);
mockSet.As<IQueryable<Blog>>().Setup(m => m.ElementType).Returns(data.ElementType);
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(data.GetEnumerator());
var mockContext = new Mock<BloggingContext>();
mockContext.Setup(c => c.Blogs).Returns(mockSet.Object);
I'm reviewing code of my colleague who introduced Sql Server Ce into the test to replace this approach.
I'm wondering if introducing something like a fake in-memory Db defeats the idea of unit testing (because our test should not depend on an external implementation) and maybe overkill
I feel that the current approach is somewhat similar because it's also using in-memory data. This is also said in the link (maybe it's not overkill and more reliable because we don't depend on an external implementation, I'm not sure that why I'm asking this question):
In-memory test doubles can be a good way to provide unit test level coverage of bits of your application that use EF. However, when doing this you are using LINQ to Objects to execute queries against in-memory data. This can result in different behavior than using EF’s LINQ provider (LINQ to Entities) to translate queries into SQL that is run against your database.
As an alternative, maybe we don't need to insert and update data and then query again so see if the data is updated correctly, we just need to see if our mocked methods were called with our expected data.
Could you guys suggest which is the better solution? (or pros and cons of each so that I can consider)? Thanks.
Aucun commentaire:
Enregistrer un commentaire