Simplified Unit Testing with the Entity Framework Core InMemory Provider | Jason Taylor [LATEST]

|| Subscribe for more content from SSW TV ||

|| Press like and leave a comment below to let us know how we're doing ||

Twitter ↴

Facebook ↴

--- Description ---

In this talk, we’ll look at how using the EF Core InMemory Provider will simplify your unit testing approach.

We will discuss the typical approach versus the simplified approach, limitations, and other considerations. You will walk away ready to write simplified unit tests for systems that depend on EF Core.

Credits:

------------------------------------------------------------------------------

Created by SSW TV | Videos By Developers, For Developers.

[gamerfawaz]

Amazing totally amazing, how simple it is, I have spent 15 days in studying different arch, and how to implement TDD, Thumbs Up simply

[IldarIsm]

This is what i have looked before!!! I did not liked custom repositories around DbContext. But I have poor knowledge how to write simple unit tests not integration tests.

[TheDanilodomingos]

Hi tks for this video! But a little advice... disable the other.

[Ardalis]

This is an effective way to write some integration tests quickly, but they're not unit tests since by definition unit tests only depend on your code, not third party dependencies (like EF Core). Not to say this isn't an awesome technique, just don't confuse things by calling them unit tests. You try to address this at 23:00 by saying the intent of the tests is to test your code, but the intent isn't the only important aspect. The issue (as you get to in the next slide) is that the tests rely on EF Core and its integration with the system-under-test to work. Unit tests shouldn't rely on integration with third-party frameworks to work - if they do, they're integration tests.

A bit later you discuss Repository and Unit of Work, claiming that EF Core implements Repository and Unit of Work, which is partially true, but then you go on to claim that if you abstract away EF Core you're "abstracting an abstraction, " which is incorrect. You're abstracting an implementation. The entire point and value of the Repository and UoW patterns is that you own the abstractions your code uses (ISP) and that these abstractions do not rely on implementation details (DIP). If you simply wire your code up to EF Core, you're stuck with whatever methods it exposes and you're tied to its implementation details, which violates ISP and DIP (of SOLID). That's not to say you can't write working software this way, but it's not following SOLID and it's not using Repository and UoW patterns since the intent of these patterns is the reliance on implementation-ignorant abstractions, not concretions.