Any unit testing methods that use EF or Linq?
I am writing unit tests for my service layer, and I fully see the point of creating unit tests to test the logic. For example, if I create a function that adds two numbers, be sure to write a unit test for that.
But if in my service level method I have something like this
public ICollection<MyEntity> GetAll()
{
return _context.MyEntities
.Where(e => !e.IsDeleted)
.ToList();
}
What's the point of unit testing? Since I am getting this from the database, it seems silly to mock the database because I am just assuming Linq is working as it should?
It wouldn't be better to test this against an actual "test" database with the same data. This way I can find out if the number of records retrieved from the database is what I expect?
I know testing with a database makes this more of an integration test, but is this really applicable for unit testing?
What if I take another example, say this
public int Delete(long id)
{
_context.Database.ExecuteCommand("DELETE FROM myTable WHERE Id = ?", id);
return _context.SaveChanges();
}
How can you test this feature? If I mock _context.Database and create a unit test that checks if _context.SaveChanges is called (which I see no point in ever doing), there is no guarantee that it will actually delete my data. What if I have a foreign key constraint? The mock would go through, but would the real method really fail?
I'm just starting to think that if the method doesn't actually compute some kind of logic, I don't see the point / reason for creating a unit test, especially when using the Entity framework?
source to share
I think it makes sense to unit test almost all types of functions:
"What's the point in unit testing? Since I'm getting this from the database, it seems silly to mock the database because I'm just assuming Linq is working as it should?"
- You are not testing Linq, but you are testing a function; the function has a name
GetAllAsync
; and I can just assume that this will return all the instancesMyEntity
stored in the database. But it just returns only the deleted items; unit testing is not just about checking that a function is working correctly; it is also a way to check if this function is named correctly. -
Also this function has a problem; what if
_context.MyEntities (e =>! e.IsDeleted) returns null?
ToList
will throw an exception. Unit testing can then help you identify potential problems if you test extreme values. -
Also, unit testing forces you to use abstraction. If you cannot unit test a method, the method may have problems, you need to investigate this method and repeat the factor.
_context.Database.ExecuteCommand ("REMOVE FROM myTable WHERE Id =?", id); In my opinion, this line of code should remain somewhere else and not in the service layer (perhaps in a repository?). What if id is "-1"? how do you handle this exception?
I think it's very difficult to state a general rule of thumb about non-unit testing methods that include Linq
.
source to share
Why would you need a unit test function that adds two numbers? You are not testing the + operator any more than you are trying to test LINQ or EF. You are testing the behavior to be absolutely correct to test what you might consider "just working". If, for example, I disallowed the use of EF in your application, you would still need a test to ensure that what you replaced with a function is correct.
Where do you want to draw the line?
source to share