Automated Testing classes with an injected DbContext [duplicate]

Question

I've been working on an implementation of a service, and have found that there are a number of operations where I need to read from a database to provide a caller with certain data or objects.

In-line with the .NET DI system, I have a DbContext injected into the classes that need to retrieve data. Something like the following:

public class RepositoryImpl
{
  public RepositoryImpl(DbContext<Database> context)
  {
    _context = context;
  }

  // later

  public DtoClass GetById(string id)
  {
    return _context.Entities.FirstOrDefault(entity => entity.Id == id);
  }
}

However, to validate that the logic for retrieving the Entity by ID, I want to write automated tests. But from what I've read (for example: here), it looks like automated testing isn't really discussed for the integration point between application logic and data sources.

Is the only way to write effective automated tests for classes that inject the DbContext to provider in-memory data as a fake, then? That reads to me like an integration test unless you define a "unit" as both the DbContext and logic to interact with it, but that seems wrong to me.

What are the common practices or strategies for verifying this logic?

Answer 1

it looks like automated testing isn't really discussed for the integration point between application logic and data sources.

This is incorrect.

In unit testing, you won't have access to the database. But unit tests is only one of numerous test types. Smoke tests, system tests, load tests, stress tests and some integration and functional tests would access the database.

Be aware, however. Introducing database in your automated tests have drawbacks, especially:

• Performance. Don't expect to run thousands of tests per second like you do with unit tests, if you depend on a database.
• Conflicts between tests, especially when ran in parallel. This can usually be circumvented by using transitions that are automatically rolled back at the end of the test.
• Infrastructure. Essentially, ops need to ensure the test machines can access a database, and the database should always be available when tests are running.