Integration Testing of Entity Framework Applications

Course Overview
Hello, this is Michael L. Perry, and welcome to Integration Testing of Entity Framework Applications. I lead a team out of the Dallas office of Improving and Agile Consultancy, that builds web applications using entity framework. We've found that a good integration test suite is our greatest asset. I'd like to show you exactly how we built it, and how an integration test suite can give your team more confidence. You may have heard advice that you should spend more time on unit tests than integration tests, that unit tests would be less costly, less prone to breaking, and provide more value. In truth, we have found that the opposite is true. While we do invest in unit test, we've found that our integration test suite gives us a bigger return on our testing investment. In this course, I'll show you how integration tests pay off, and exactly how we went about constructing them. The major areas that we'll cover are continuous integration, test isolation, domain driven design, and readability. When you're done, you will have the skills to build a valuable integration test suite for your EF6, or EF Core application, but this course is not an introduction to entity framework. Before you begin, you should understand code First, fluent configuration, and migrations. Now hopefully you'll join me and follow along with my team as we build integration tests for entity framework applications, at Pluralsight.

The Importance of Testing the Data Access Layer
Hello, and welcome to Integration Testing of Entity Framework Applications, I'm Michael L. Perry. Let's talk real quick about the importance of testing the data access layer. There are many reasons that people give for not integration testing. For example, they say that integration tests are too slow, or they're brittle, they break whenever you make any change to the application, or they're hard to set up, you need to install a database and run all your migrations against it every time you want to run a test. When in fact, based on my experience on my team, we've found that integration tests help us to go faster. They give us more confidence in the changes that we're making, so we can code without fear. We've also found ways to make our integration test suite more resilient to change, so it supports changes, rather than hinders them, and we've found that nowadays, it's really easy to get them set up. There's a lot of tools that you have out of the box that are available to you right now. In this course, I want to show you exactly how to get those set up, and how you can gain these benefits. This course will cover both EF6 and EF Core, so which ever your platform your team is using, you'll find the answers right here, but before we get started, you should already have some familiarity with entity framework, and especially with migrations. Two courses that I recommend you start with are Entity Framework in the Enterprise, by Julie Lerman, and Entity Framework Migrations for Large Teams, by myself. And so, if you're all ready to go, let's get started, and talk about the importance of testing your data access layer.

Deploying a Database to the Test Environment
Welcome back to Integration Testing of Entity Framework Applications. I'm Michael L. Perry, and in this module, we're going to be deploying a database to the test environment. Now the test environment they were talking about here is continuous integration. We're not going to be deploying a database to our QA environment, that'll be up to you. We'll actually be setting up two different kinds of integration test environments, one per developer machine, and the other on the integration test server. You see, each developer is going to have their own copy of the database that they develop against, but in addition to that, they'll also have an integration test database. By keeping these two things separate, they can develop their migrations against the dev database, and then run the automated tests against their integration test database. We'll start off by defining the project structure. These will consist of the source files being a web layer, a logic layer, and a data access layer, and test files, including unit tests, and integration tests. In this module, we'll just focus on building those integration tests. Then we'll configure our integration tests to deploy a SQL database to LocalDB, so that we can run our automated tests against it. Once we've got that all configured to run locally for each developer, then we'll set up our continuous integration environment. In this course, we'll be using visualstudio. com to run our builds, but the techniques that you learn here will apply to any build server that you choose. So, let's see how to configure an integration test to initialize the database using entity framework.

Isolating Integration Tests
Welcome back to Integration Testing of Entity Framework Applications, I'm Michael L. Perry, and in this module, we're going to be talking about isolating integration tests. The difficulty of course, with testing against the database is that databases are designed to persist state. The tests that you run are going to make changes to that state, so if tests can change state, then that means that the different tests can see the changes made by other tests, and that causes dependencies. There are two ways in which dependencies arise, you can have a dependency between tests if they must be run in some predictable order. Any way you slice it, you cannot predict the order in which tests will be run, and so this kind of dependency between tests must be eliminated. The second kind of dependency arises when tests will pass in isolation on their own, but they'll fail when run together. While we're doing development, we want to run tests on their own, but of course, we want to run continuous integration over the entire test suite, and so those kind of dependencies must also be eliminated. In this module, we'll tackle two techniques for removing dependencies between tests. The first is that we'll use transactions in order to roll back a test so that it's changes aren't visible to the next test it runs. We'll see how to do this both in EF6 and in EF Core. The second technique is that we'll use unique data for each of the tests, that way, even though the data remains, the other tests won't care about it. So let's jump back into the world of Globalmantics and create our new suite of tests.

When and How to Unit Test
Welcome back to Integration Testing of Entity Framework Applications. I'm Michael L. Perry, and here in module 4 we're going to be talking about when and how to write unit tests. So far, we've been focusing on the integration tests, why it's important to write them, how to run them in continuous integration, and how to isolate them from one another, but now let's focus on the unit tests. When should we write them and how should we write them? So we're going to kick things off by having a review of Domain-Driven Design. Domain-Driven Design helps us to separate our application into layers, so we've got the entities in the domain layer, and services that are in the application layer. When we're focused on the entities, we want to write unit tests that have no dependency upon any database. These tests will be focused on the business logic of our problem domain, but then we'll also want to make sure that we cover our services with tests. Services integrate several different entities together, and they access the database, so we're going to need to have an in-memory database to write our unit tests, or the real database while we're writing our integration tests. So here we'll want to have a combination of the two kinds of tests. Unit tests will help us to test drive our services because they give us a really tight feedback loop, but integration tests are still necessary because the in-memory databases that we'll be using don't completely replicate the behavior of a relational database. For instance, we'll need the integration tests to cover things like mapping configurations, migrations, queries, includes, and constraints. So let's do a quick review of Domain-Driven Design so that we can jump into unit testing our domain models.