Testing

When talking about the Dependency Inversion Principle, the D in SOLID, we have a pretty good idea of what dependencies we’re trying to abstract away. OrderRepository or SendGridEmailClient are easy examples of implementations we should abstract away. It also overlaps well with the Single Responsibility Principle, since data access for orders and sending emails are separated from the business logic where they are used. The C# implementation of this would involve making these classes implement the appropriate interfaces, e.

Introduction First off, let me make a few assumptions if you’re reading this article and trying to mock with Entity Framework 6: You’re on a legacy codebase. If you weren’t you’d be using Entity Framework Core and the In-Memory Provider. You’re not utilizing Database Migrations. If you were, it may probably be easier to create a new database and run tests using localDb. Your schema is extremely large. With a large database schema (often seen in legacy systems) data setup can become extremely difficult.

A Little Background I’m usually a stickler for best practices, but automated testing is something that has eluded me in my professional career for a long time. I typically work on legacy, line of business applications. So automated testing was never a priority. I’ve tried and failed to introduce various development teams to automated testing. Legacy applications are inherently difficult to test. Most everything I’ve read about automated testing points to trivial examples of testing and something like add (1, 2) and making sure the output was 3.