Тестирование без системы рабочих баз данных
На этой странице мы обсудим методы написания автоматических тестов, которые не включают систему базы данных, с которой приложение работает в рабочей среде, переключив базу данных на тест двойной. Существуют различные типы тестов двойных и подходов для этого, и рекомендуется тщательно прочитать стратегию тестирования, чтобы полностью понять различные варианты. Наконец, можно также протестировать систему рабочей базы данных; это рассматривается в разделе "Тестирование в рабочей системе базы данных".
Совет
На этой странице показаны методы xUnit, но аналогичные понятия существуют в других платформах тестирования, включая NUnit.
Шаблон репозитория
Если вы решили написать тесты без участия в рабочей системе базы данных, рекомендуемый способ для этого — шаблон репозитория; Дополнительные сведения об этом см . в этом разделе. Первым шагом реализации шаблона репозитория является извлечение запросов EF Core LINQ на отдельный слой, который мы позже заглушку или макет. Ниже приведен пример интерфейса репозитория для системы блогов:
public interface IBloggingRepository
{
Blog GetBlogByName(string name);
IEnumerable<Blog> GetAllBlogs();
void AddBlog(Blog blog);
void SaveChanges();
}
... и вот частичная реализация для использования в рабочей среде:
public class BloggingRepository : IBloggingRepository
{
private readonly BloggingContext _context;
public BloggingRepository(BloggingContext context)
=> _context = context;
public Blog GetBlogByName(string name)
=> _context.Blogs.FirstOrDefault(b => b.Name == name);
// Other code...
}
Это не так много: репозиторий просто упаковывает контекст EF Core и предоставляет методы, которые выполняют запросы и обновления базы данных. Важно отметить, что наш GetAllBlogs
метод возвращается IEnumerable<Blog>
, а не IQueryable<Blog>
. Возврат последнего означает, что операторы запросов по-прежнему могут быть составлены по результату, требуя, чтобы EF Core по-прежнему участвовал в переводе запроса; это приведет к поражению цели наличия репозитория в первую очередь. IEnumerable<Blog>
позволяет нам легко заглушить или издеваться над тем, что возвращает репозиторий.
Для приложения ASP.NET Core необходимо зарегистрировать репозиторий в качестве службы при внедрении зависимостей, добавив следующее в ConfigureServices
приложение:
services.AddScoped<IBloggingRepository, BloggingRepository>();
Наконец, наши контроллеры внедряются в службу репозитория вместо контекста EF Core и выполняют методы в нем:
private readonly IBloggingRepository _repository;
public BloggingControllerWithRepository(IBloggingRepository repository)
=> _repository = repository;
[HttpGet]
public Blog GetBlog(string name)
=> _repository.GetBlogByName(name);
На этом этапе приложение создается в соответствии с шаблоном репозитория: единственная точка контакта с уровнем доступа к данным — EF Core — теперь через уровень репозитория, который выступает в качестве посредника между кодом приложения и фактическими запросами базы данных. Теперь тесты можно писать просто путем разбиения из репозитория или издеваться над ним с любимой библиотекой макетирования. Ниже приведен пример теста на основе макета с помощью популярной библиотеки Moq :
[Fact]
public void GetBlog()
{
// Arrange
var repositoryMock = new Mock<IBloggingRepository>();
repositoryMock
.Setup(r => r.GetBlogByName("Blog2"))
.Returns(new Blog { Name = "Blog2", Url = "http://blog2.com" });
var controller = new BloggingControllerWithRepository(repositoryMock.Object);
// Act
var blog = controller.GetBlog("Blog2");
// Assert
repositoryMock.Verify(r => r.GetBlogByName("Blog2"));
Assert.Equal("http://blog2.com", blog.Url);
}
Полный пример кода можно просмотреть здесь.
SQLite в памяти
SQLite можно легко настроить в качестве поставщика EF Core для набора тестов вместо рабочей системы базы данных (например, SQL Server); Дополнительные сведения см. в документации по поставщику SQLite. Однако обычно рекомендуется использовать функцию базы данных SQLite в памяти при тестировании, так как она обеспечивает простую изоляцию между тестами и не требует работы с фактическими файлами SQLite.
Чтобы использовать SQLite в памяти, важно понимать, что новая база данных создается при открытии низкоуровневого подключения и удаляется при закрытии этого подключения. При обычном использовании EF Core DbContext
открывается и закрывается подключения к базе данных по мере необходимости - каждый раз при выполнении запроса, чтобы избежать ненужных операций подключения. Однако при использовании SQLite в памяти это приведет к сбросу базы данных каждый раз; Поэтому в качестве обходного решения мы открываем подключение перед передачей в EF Core и упорядочение его закрытия только после завершения теста:
public SqliteInMemoryBloggingControllerTest()
{
// Create and open a connection. This creates the SQLite in-memory database, which will persist until the connection is closed
// at the end of the test (see Dispose below).
_connection = new SqliteConnection("Filename=:memory:");
_connection.Open();
// These options will be used by the context instances in this test suite, including the connection opened above.
_contextOptions = new DbContextOptionsBuilder<BloggingContext>()
.UseSqlite(_connection)
.Options;
// Create the schema and seed some data
using var context = new BloggingContext(_contextOptions);
if (context.Database.EnsureCreated())
{
using var viewCommand = context.Database.GetDbConnection().CreateCommand();
viewCommand.CommandText = @"
CREATE VIEW AllResources AS
SELECT Url
FROM Blogs;";
viewCommand.ExecuteNonQuery();
}
context.AddRange(
new Blog { Name = "Blog1", Url = "http://blog1.com" },
new Blog { Name = "Blog2", Url = "http://blog2.com" });
context.SaveChanges();
}
BloggingContext CreateContext() => new BloggingContext(_contextOptions);
public void Dispose() => _connection.Dispose();
Теперь тесты могут вызываться CreateContext
, возвращая контекст с помощью подключения, настроенного в конструкторе, обеспечивая наличие чистой базы данных с заполненными данными.
Полный пример кода для тестирования в памяти SQLite можно просмотреть здесь.
Поставщик с размещением в памяти
Как описано на странице обзора тестирования, использование поставщика в памяти для тестирования настоятельно не рекомендуется; рекомендуется использовать SQLite вместо этого или реализовать шаблон репозитория. Если вы решили использовать в памяти, ниже приведен типичный конструктор класса тестирования, который настраивает и создает новую базу данных в памяти перед каждым тестом:
public InMemoryBloggingControllerTest()
{
_contextOptions = new DbContextOptionsBuilder<BloggingContext>()
.UseInMemoryDatabase("BloggingControllerTest")
.ConfigureWarnings(b => b.Ignore(InMemoryEventId.TransactionIgnoredWarning))
.Options;
using var context = new BloggingContext(_contextOptions);
context.Database.EnsureDeleted();
context.Database.EnsureCreated();
context.AddRange(
new Blog { Name = "Blog1", Url = "http://blog1.com" },
new Blog { Name = "Blog2", Url = "http://blog2.com" });
context.SaveChanges();
}
Полный пример кода для тестирования в памяти можно просмотреть здесь.
Именование базы данных в памяти
Базы данных в памяти идентифицируются простым, строковым именем и можно подключиться к одной базе данных несколько раз, указав то же имя (именно поэтому пример выше должен вызываться EnsureDeleted
перед каждым тестом). Тем не менее обратите внимание, что базы данных в памяти коренятся во внутреннем поставщике услуг контекста; хотя в большинстве случаев контексты совместно используют одного поставщика услуг, настройка контекстов с разными параметрами может активировать использование нового внутреннего поставщика услуг. В этом случае явно передайте один и тот же экземпляр InMemoryDatabaseRootUseInMemoryDatabase
для всех контекстов, которые должны совместно использовать базы данных в памяти (обычно это делается путем статического InMemoryDatabaseRoot
поля).
Проводки
Обратите внимание, что по умолчанию, если транзакция запущена, поставщик в памяти вызовет исключение, так как транзакции не поддерживаются. Вместо этого может потребоваться без учета транзакций, настроив EF Core игнорировать InMemoryEventId.TransactionIgnoredWarning
как в приведенном выше примере. Однако если код на самом деле зависит от семантики транзакций, например, зависит от отката фактически отката изменений - тест не будет работать.
Представления
Поставщик в памяти позволяет определение представлений с помощью запросов LINQ с помощью ToInMemoryQuery:
modelBuilder.Entity<UrlResource>()
.ToInMemoryQuery(() => context.Blogs.Select(b => new UrlResource { Url = b.Url }));