Continuing the series of posts to explore different testing aspects in asp .net core. We’re going experiment with Test Server to create integration tests.
Test Server is a new features that asp .net core is bringing. It creates a browser abstraction, allowing us to simulate application’s behavior without opening a browser.
There are many ways to deal with the database in integration tests. The idea is to not affect the data that’s already in the database. We could use an entirely different database, creating and deleting it every time we run our tests.
Other approach is to use the same database as the application, but clean up data after each test. For example, if we add a register into the database and in the end of the test we remove it.
We can follow a transactional approach. Which means that we create a transaction scope within each unit test to not commit changes when we call .SaveChanges(). Then, when the test is over, this transaction is disposed and no changes are committed to the database.
Entity Framework Core In-Memory database could also be used. Following this approach we won’t have to worry about storing data. But, how can we call this an integration test if we aren’t using a real database? Yeah, that’s right, this approach will fall into the unit test category.
For this post, we’re going to use the transactional approach.
Top comments (0)