프로덕션 데이터베이스 시스템에 대한 테스트

아티클
10/05/2023

이 페이지에서는 애플리케이션이 프로덕션 환경에서 실행되는 데이터베이스 시스템과 관련된 자동화 테스트를 작성하는 기술에 대해 설명합니다. 프로덕션 데이터베이스 시스템이 테스트 더블로 교환되는 대체 테스트 접근 방식이 있습니다. 자세한 내용은 테스트 개요 페이지를 참조하세요. 프로덕션 환경에 사용되는 데이터베이스와 다른 데이터베이스(예: Sqlite)는 테스트 더블로 사용되므로 다른 데이터베이스에 대한 테스트는 여기에서 다루지 않습니다. 이 접근 방식은 프로덕션 데이터베이스 시스템 없이 테스트에서 설명합니다.

실제 데이터베이스와 관련된 테스트의 주요 장애물은 병렬(또는 직렬)로 실행하는 테스트가 서로 간섭하지 않도록 테스트를 적절하게 격리하는 것입니다. 아래의 전체 샘플 코드는 여기에서 볼 수 있습니다.

팁

이 페이지에서는 xUnit 기술을 소개하지만 NUnit을 포함한 다른 테스트 프레임워크에도 유사한 개념이 있습니다.

데이터베이스 시스템 설정

오늘날 대부분의 데이터베이스 시스템은 CI 환경과 개발자 컴퓨터에서 모두 쉽게 설치할 수 있습니다. 일반 설치 메커니즘을 통해 데이터베이스를 쉽게 설치할 수 있는 경우가 많지만 즉시 사용 가능한 Docker 이미지를 대부분의 주요 데이터베이스에서 사용할 수 있으며 CI에서 특히 쉽게 설치할 수 있습니다. 개발자 환경의 경우, GitHub 작업 영역, 개발자 컨테이너에서 데이터베이스를 비롯하여 필요한 모든 서비스와 종속성을 설정할 수 있습니다. 이렇게 하려면 설정에 대한 초기 투자가 필요하지만 설정이 완료되면 작업 테스트 환경이 갖추어져 더 중요한 일에 집중할 수 있습니다.

경우에 따라 데이터베이스에는 테스트에 유용할 수 있는 특수 버전이 있습니다. SQL Server를 사용하는 경우 LocalDB를 사용하여 사실상 전혀 설정하지 않은 상태에서 로컬에서 테스트를 실행할 수 있으며, 필요에 따라 데이터베이스 인스턴스를 스핀업하고 상대적으로 약한 개발자 시스템에서 리소스를 절약할 수도 있습니다. 하지만 LocalDB에도 다음과 같은 문제가 있습니다.

SQL Server Developer Edition이 지원하는 모든 기능을 지원하지는 않습니다.
Windows에서만 사용할 수 있습니다.
서비스가 실행될 때 첫 번째 테스트 실행에서 지연이 발생할 수 있습니다.

일반적으로 LocalDB보다 SQL Server Developer 버전을 설치하는 것이 좋습니다. 전체 SQL Server 기능 집합이 있고 대체로 쉽게 설치할 수 있기 때문입니다.

클라우드 데이터베이스를 사용할 때 속도를 높이고 비용을 절감하려면 일반적으로 로컬 버전의 데이터베이스에 대해 테스트하는 것이 적절합니다. 예를 들어 프로덕션 환경에서 SQL Azure를 사용하는 경우 로컬에 설치된 SQL Server에 대해 테스트해볼 수 있습니다. 두 버전이 매우 유사하기 때문입니다. 그러나 프로덕션 환경으로 전환하기 전에 SQL Azure 자체에 대해 테스트를 실행하는 것이 가장 좋습니다. Azure Cosmos DB를 사용할 경우 Azure Cosmos DB 에뮬레이터는 로컬에서 개발하고 테스트를 실행하는 데 유용한 도구가 됩니다.

테스트 데이터베이스 만들기, 시드 및 관리

데이터베이스가 설치되면 이제 테스트에서 데이터베이스를 사용해볼 수 있습니다. 대부분의 단순한 경우, 테스트 도구 모음에는 여러 테스트 클래스에서 여러 테스트 간에 공유되는 단일 데이터베이스가 있으므로 테스트 실행 기간 동안 데이터베이스가 정확히 한 번 만들어지고 시드되도록 하는 몇 가지 논리가 필요합니다.

Xunit을 사용할 경우에는 데이터베이스를 나타내고 여러 테스트 실행에서 공유되는 클래스 픽스쳐를 통해 이를 수행할 수 있습니다.

public class TestDatabaseFixture
{
    private const string ConnectionString = @"Server=(localdb)\mssqllocaldb;Database=EFTestSample;Trusted_Connection=True;ConnectRetryCount=0";

    private static readonly object _lock = new();
    private static bool _databaseInitialized;

    public TestDatabaseFixture()
    {
        lock (_lock)
        {
            if (!_databaseInitialized)
            {
                using (var context = CreateContext())
                {
                    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();
                }

                _databaseInitialized = true;
            }
        }
    }

    public BloggingContext CreateContext()
        => new BloggingContext(
            new DbContextOptionsBuilder<BloggingContext>()
                .UseSqlServer(ConnectionString)
                .Options);
}

위 픽스쳐가 인스턴스화되면 EnsureDeleted()를 사용하여 데이터베이스를 제거한 다음(이전 실행에서 데이터베이스가 있는 경우), EnsureCreated()를 사용하여 최신 모델 구성으로 만듭니다(해당 API에 대한 문서 참조). 데이터베이스가 만들어지면 픽스쳐가 테스트에서 사용할 수 있는 일부 데이터를 데이터베이스에 시드합니다. 새 테스트를 위해 나중에 변경하면 기존 테스트가 실패할 수 있으므로 시드 데이터에 대해 시간을 갖고 생각할 가치가 있습니다.

테스트 클래스에서 픽스쳐를 사용하려는 경우, 픽스쳐 형식에 IClassFixture만 구현하면 xUnit에서 이를 생성자에 삽입합니다.

public class BloggingControllerTest : IClassFixture<TestDatabaseFixture>
{
    public BloggingControllerTest(TestDatabaseFixture fixture)
        => Fixture = fixture;

    public TestDatabaseFixture Fixture { get; }

이제 테스트 클래스에는 모든 기능을 갖춘 컨텍스트 인스턴스를 만들기 위해 테스트에서 사용할 수 있는 Fixture 속성이 있습니다.

[Fact]
public void GetBlog()
{
    using var context = Fixture.CreateContext();
    var controller = new BloggingController(context);

    var blog = controller.GetBlog("Blog2").Value;

    Assert.Equal("http://blog2.com", blog.Url);
}

마지막으로 위의 픽스쳐 생성 논리에서 일부 잠금이 있다는 것을 발견했을 것입니다. 픽스쳐가 단일 테스트 클래스에서만 사용되는 경우 xUnit으로 정확히 한 번은 인스턴스화할 수 있습니다. 그러나 여러 테스트 클래스에서 동일한 데이터베이스 픽스쳐를 사용하는 것이 일반적입니다. xUnit은 컬렉션 픽스쳐를 제공하지만 이 메커니즘은 테스트 클래스가 병렬로 실행할 수 없도록 하는데 이는 테스트 성능에 중요합니다. xUnit 클래스 픽스쳐를 사용하여 안전하게 관리하려면 데이터베이스 만들기 및 시드에 대해 간단한 잠금을 설정하고 정적 플래그를 사용하여 두 번 수행할 필요가 없도록 합니다.

데이터를 수정하는 테스트

위의 예제는 읽기 전용 테스트이며 테스트 격리 관점에서 볼 때 쉽고 수정 사항이 없으므로 테스트 간섭이 불가능합니다. 반면 데이터를 수정하는 테스트는 서로 간섭할 수 있으므로 더 문제가 됩니다. 쓰기 테스트를 격리하는 일반적인 기술 중 하나는 트랜잭션에서 테스트를 래핑하고 테스트가 끝날 때 해당 트랜잭션을 롤백하는 것입니다. 실제로 데이터베이스에 커밋된 항목이 없으므로 다른 테스트에는 수정 사항이 표시되지 않으며 간섭을 피할 수 있습니다.

다음은 데이터베이스에 블로그를 추가하는 컨트롤러 메서드입니다.

[HttpPost]
public ActionResult AddBlog(string name, string url)
{
    _context.Blogs.Add(new Blog { Name = name, Url = url });
    _context.SaveChanges();

    return Ok();
}

다음을 사용하여 이 메서드를 테스트할 수 있습니다.

[Fact]
public void AddBlog()
{
    using var context = Fixture.CreateContext();
    context.Database.BeginTransaction();

    var controller = new BloggingController(context);
    controller.AddBlog("Blog3", "http://blog3.com");

    context.ChangeTracker.Clear();

    var blog = context.Blogs.Single(b => b.Name == "Blog3");
    Assert.Equal("http://blog3.com", blog.Url);

}

위의 테스트 코드에 대한 몇 가지 참고 사항:

아래 변경 사항이 데이터베이스에 커밋되지 않고 다른 테스트를 간섭하지 않도록 트랜잭션을 시작합니다. 트랜잭션은 커밋되지 않으므로 컨텍스트 인스턴스가 삭제될 때 테스트 마지막에 암시적으로 롤백됩니다.
원하는 업데이트를 수행한 후 ChangeTracker.Clear를 사용하여 컨텍스트 인스턴스의 변경 사항 추적기를 지우고 아래 데이터베이스에서 실제로 블로그를 로드하는지 확인합니다. 대신 두 컨텍스트 인스턴스를 사용할 수 있지만 두 인스턴스에서 동일한 트랜잭션이 사용되는지 확인해야 합니다.
테스트가 이미 트랜잭션에 있고 업데이트할 준비가 된 컨텍스트 인스턴스를 받도록 픽스쳐의 CreateContext에서 트랜잭션을 시작할 수도 있습니다. 이렇게 하면 트랜잭션이 실수로 잊혀져 디버그하기 어려울 수 있는 테스트 간섭이 발생하지 않도록 방지할 수 있습니다. 또한 읽기 전용 테스트와 쓰기 테스트를 서로 다른 테스트 클래스로 분리할 수도 있습니다.

트랜잭션을 명시적으로 관리하는 테스트

추가적인 어려움을 수반하는 테스트의 최종 범주는 데이터를 수정하고 트랜잭션을 명시적으로 관리하는 테스트입니다. 데이터베이스는 일반적으로 중첩 트랜잭션을 지원하지 않으므로 격리를 위해 트랜잭션을 사용할 수 없습니다. 실제 제품 코드에서 사용해야 하기 때문입니다. 이러한 테스트는 비교적 드문 경향이 있지만 특수한 방식으로 처리해야 합니다. 각 테스트 후에는 데이터베이스를 원래 상태로 정리해야 하며 병렬화를 사용하지 않도록 설정하여 테스트가 서로 간섭하지 않게 해야 합니다.

다음 컨트롤러 메서드를 예로 살펴보겠습니다.

[HttpPost]
public ActionResult UpdateBlogUrl(string name, string url)
{
    // Note: it isn't usually necessary to start a transaction for updating. This is done here for illustration purposes only.
    using var transaction = _context.Database.BeginTransaction(IsolationLevel.Serializable);

    var blog = _context.Blogs.FirstOrDefault(b => b.Name == name);
    if (blog is null)
    {
        return NotFound();
    }

    blog.Url = url;
    _context.SaveChanges();

    transaction.Commit();
    return Ok();
}

일반적이지 않지만 특정 이유로 메서드에 직렬화 가능한 트랜잭션을 사용해야 한다고 가정해 보겠습니다. 결과적으로는 트랜잭션을 사용하여 테스트 격리를 보장할 수 없습니다. 테스트는 실제로 데이터베이스에 대한 변경 사항을 커밋하므로 앞서 표시된 다른 테스트를 방해하지 않도록 별도의 자체 데이터베이스를 사용하여 다른 픽스쳐를 정의합니다.

public class TransactionalTestDatabaseFixture
{
    private const string ConnectionString = @"Server=(localdb)\mssqllocaldb;Database=EFTransactionalTestSample;Trusted_Connection=True;ConnectRetryCount=0";

    public BloggingContext CreateContext()
        => new BloggingContext(
            new DbContextOptionsBuilder<BloggingContext>()
                .UseSqlServer(ConnectionString)
                .Options);

    public TransactionalTestDatabaseFixture()
    {
        using var context = CreateContext();
        context.Database.EnsureDeleted();
        context.Database.EnsureCreated();

        Cleanup();
    }

    public void Cleanup()
    {
        using var context = CreateContext();

        context.Blogs.RemoveRange(context.Blogs);

        context.AddRange(
            new Blog { Name = "Blog1", Url = "http://blog1.com" },
            new Blog { Name = "Blog2", Url = "http://blog2.com" });
        context.SaveChanges();
    }
}

이 픽스쳐는 위에서 사용한 것과 유사하지만 특별히 Cleanup 메서드를 포함하며 데이터베이스가 시작 상태로 초기화되었는지 확인하기 위해 테스트가 끝날 때마다 호출됩니다.

이 픽스쳐가 단일 테스트 클래스에서만 사용되는 경우 위와 같이 클래스 픽스쳐로 참조할 수 있습니다. xUnit은 동일한 클래스 내의 테스트를 병렬화하지 않습니다(xUnit 문서에서 테스트 컬렉션 및 병렬화에 대해 자세히 참조). 그러나 여러 클래스 간에 이 픽스쳐를 공유하려는 경우 간섭을 방지하기 위해 해당 클래스가 병렬로 실행되지 않도록 해야 합니다. 따라서 이 픽스쳐를 클래스 픽스쳐가 아닌 xUnit 컬렉션 픽스쳐로 사용할 것입니다.

먼저, 픽스쳐를 참조하고 필요한 모든 트랜잭션 테스트 클래스에서 사용되는 테스트 컬렉션을 정의합니다.

[CollectionDefinition("TransactionalTests")]
public class TransactionalTestsCollection : ICollectionFixture<TransactionalTestDatabaseFixture>
{
}

이제 테스트 클래스에서 테스트 컬렉션을 참조하고 이전과 같이 생성자의 픽스쳐를 허용합니다.

[Collection("TransactionalTests")]
public class TransactionalBloggingControllerTest : IDisposable
{
    public TransactionalBloggingControllerTest(TransactionalTestDatabaseFixture fixture)
        => Fixture = fixture;

    public TransactionalTestDatabaseFixture Fixture { get; }

마지막으로 테스트 클래스를 삭제할 수 있도록 하여 각 테스트 후에 픽스쳐의 Cleanup 메서드를 호출하도록 정렬합니다.

public void Dispose()
    => Fixture.Cleanup();

xUnit은 컬렉션 픽스쳐를 한 번만 인스턴스화하므로 위와 같이 데이터베이스 만들기 및 시드에 대한 잠금을 사용할 필요가 없습니다.

위의 전체 샘플 코드는 여기에서 볼 수 있습니다.

팁

데이터베이스를 수정하는 테스트가 포함된 테스트 클래스가 여러 개 있는 경우 각 자체 데이터베이스를 참조하는 서로 다른 픽스쳐를 사용하여 해당 테스트 클래스를 병렬로 실행할 수 있습니다. 많은 테스트 데이터베이스를 만들고 사용하는 것은 문제가 되지 않으며 도움이 될 때마다 수행해야 합니다.

효율적인 데이터베이스 만들기

위의 샘플에서는 테스트를 실행하기 전에 EnsureDeleted()와 EnsureCreated()를 사용하여 최신 테스트 데이터베이스가 있는지 확인했습니다. 일부 데이터베이스에서는 이 작업이 다소 느릴 수 있으며 이는 코드 변경을 반복하고 테스트를 계속 다시 실행할 때 문제가 될 수 있습니다. 이 경우 픽스쳐의 생성자에서 일시적으로 EnsureDeleted를 주석 처리할 수 있습니다. 이렇게 하면 테스트 실행에서 동일한 데이터베이스가 다시 사용됩니다.

이 방법은 EF Core 모델을 변경하는 경우 데이터베이스 스키마가 최신 상태가 되지 않으며 테스트가 실패할 수 있다는 단점이 있습니다. 따라서 개발 주기 동안에만 일시적으로 수행하는 것이 좋습니다.

효율적인 데이터베이스 정리

위에서 변경 사항이 실제로 데이터베이스에 커밋되면 간섭을 방지하기 위해 각 테스트 사이에 데이터베이스를 정리해야 한다는 것을 확인했습니다. 위의 트랜잭션 테스트 샘플에서는 EF Core API로 테이블 내용을 삭제하여 정리했습니다.

using var context = CreateContext();

context.Blogs.RemoveRange(context.Blogs);

context.AddRange(
    new Blog { Name = "Blog1", Url = "http://blog1.com" },
    new Blog { Name = "Blog2", Url = "http://blog2.com" });
context.SaveChanges();

일반적으로 이 방법은 테이블을 가장 효율적으로 지우는 방법은 아닙니다. 테스트 속도가 문제되는 경우 원시 SQL을 사용하여 테이블을 삭제하는 것이 더 좋습니다.

DELETE FROM [Blogs];

데이터베이스를 효율적으로 지우는 respawn 패키지를 사용하는 것도 고려할 수 있습니다. 또한 지울 테이블을 지정할 필요가 없으므로 모델에 테이블이 추가될 때 정리 코드를 업데이트할 필요가 없습니다.

요약

실제 데이터베이스에 대해 테스트할 때는 다음 테스트 범주를 구분할 필요가 있습니다.
- 읽기 전용 테스트는 비교적 간단하며 격리 걱정 없이 항상 동일한 데이터베이스에 대해 병렬로 실행할 수 있습니다.
- 쓰기 테스트는 더 문제가 될 수 있지만 트랜잭션을 사용하여 제대로 격리되었는지 확인할 수 있습니다.
- 트랜잭션 테스트는 가장 문제가 되며 데이터베이스를 원래 상태로 초기화하고 병렬화를 사용하지 않도록 설정하는 논리가 필요합니다.
이러한 테스트 범주를 별도의 클래스로 분리하면 테스트 사이에 발생할 수 있는 혼란 또는 우발적인 간섭을 방지할 수 있습니다.
시드된 테스트 데이터를 미리 생각해보고 시드 데이터가 변경되어도 너무 자주 중단되지 않는 방식으로 테스트를 작성해 보세요.
여러 데이터베이스를 사용하여 데이터베이스를 수정하는 테스트를 병렬화하고 다른 시드 데이터 구성을 허용할 수도 있습니다.
테스트 속도가 문제되는 경우 테스트 데이터베이스를 만들고 실행 간 데이터 정리를 위한 보다 효율적인 기술을 살펴볼 수 있습니다.
항상 테스트 병렬화 및 격리를 염두에 두어야 합니다.

다음을 통해 공유