You could write a single test codebase, and run it twice - one with in-memory and one with the real thing, but that has other problems. Which led us to wonder - if we were writing the tests twice, what was the value of having two tests? Those unit tests with in-memory looked exactly like the integration tests, just with a different provider. Even with writing in-memory tests, we still absolutely wrote integration tests against a real database. You MUST write a real integration test anywayįirst and foremost, an in-memory provider is a pale imitation for the real thing. Our teams tried a number of years ago to speed up integration tests by swapping in-memory providers, but we found a number of problems with this approach that led us to abandoning it altogether. Yikes! We also have async in the mix, so now we're at the point where the IQueryable isn't remotely the same for in-memory.īut that won't stop us from trying! Pitfalls of In-Memory So you have to extend IQueryable to do fun things like: using (var context = new BloggingContext()) On top of that, a good deal of the LINQ surface area can't be translated into SQL, and there are Very Important things that don't translate into LINQ.
We're trying to wrap a fit-for-purpose API with a generic-purpose API, and one that can run either in-memory or translated into a database.
LINQ surfaces a great amount of flexibility, but that flexibility makes it quite difficult to translate into SQL or any other database API that's already been specifically designed for that database. This is unlike other ORMs that provide a specialized API or language, such as NHibernate or the MongoDB C# driver.
#Oracle database inmemory how to#
You have to do similar operations as an actual compiler, dealing with ASTs, building your own AST (often), and figuring out how to make a very wide and complex API that is all the IQueryable surface area.Īny ORM maintainer can tell you - the code in the query provider can dwarf the code in the rest of the codebase.
It's a transpiler, but instead of the output being text, it's API calls. Why is that?Ī LINQ provider is a compiler, a lexer, and a parser, but doesn't own any of those pieces. They're not even merely difficult, they're some of the most complex pieces of code you'll see. It all seems so simple, but unfortunately, the devil is in the details. So why not take advantage of this possibility for unit tests? Why not allow us to swap the implementation of some queryable to the in-memory equivalent, and allow us to write unit tests against in-memory stores? There's a neat trick that you can do, however, as IEnumerable has a method, AsQueryable, to allow complex expression trees to evaluate directly against an in-memory IEnumerable. With IQueryable, an IQueryProvider translates expression trees to.well whatever makes sense for the underlying store. LINQ has two flavors - IEnumerable and IQueryable. It seems rather simple at first - especially in the. It's something our teams learned nearly a decade ago, that trying to swap out an in-memory strategy for unit testing simply doesn't provide the value folks may hope for. This seemed like a no-brainer to me - these database providers are far from trivial to maintain, even for in-memory strategies. A controversial GitHub issue came to my attention a couple of weeks ago around ditching the in-memory provider for Entity Framework Core.
0 kommentar(er)
