3 ms·

You mean using interfaces and integration tests?

• uticus 4y ago
  > using interfaces Kinda, but personally I describe as using LINQ queries. The dbcontext just isn't hooked up. It's a method that takes in an IQueryable<T> (there's the interface I suppose) and outputs a filtered IQueryable<T>. The unit test (see my next response) provides a test collection and expects a certain result. > and integration tests No, unit tests
  • joshschreuder 4y ago
    Just as a real world (somewhat) counterpoint to this - you need to be very careful about performance metrics in particular. Functionality is pretty easy to verify with LINQ / mock data sets (though it is also easy to mock things in a way that aren't representative of real data by mistake) but the performance characteristics of a real SQL engine vs. unit testing in this way can lead to some real gotchas once it's deployed. Particularly if you're using an ORM, multiple enumerations over database queries, strange ORM choices in joins/exists/whatever can absolutely murder performance. I would still recommend having integration and/or performance testing downstream of these types of unit tests though I agree they are useful.
    • uticus 4y ago
      great point and agree - and, actually it argues even better against my point #1 about moving business logic out of SQL queries.