運用データベースシステムに対するテスト

[アーティクル]
08/24/2023

このページでは、運用環境で実行するアプリケーション用のデータベースシステムを使用する自動テストを作成する手法について説明します。運用データベースシステムをテストダブルに置き換える別のテストアプローチが存在します。詳細については、テストの概要ページを参照してください。運用環境で使用されるデータベース (Sqlite など) とは異なるデータベースに対するテストについては、ここでは説明しません。これは、異なるデータベースがテストダブルとして使用されるためです。このアプローチについては、「運用データベースシステムを使用しないテスト」で説明しています。

実際のデータベースを使用するテストに伴う主な困難は、並列で (またはシリアルであっても) 実行されるテストが相互に干渉しないように、適切なテストの分離を確実に行うことです。以下のサンプルコードの全体はここで確認できます。

ヒント

このページは xUnit 手法を示していますが、NUnit などの他のテストフレームワークにも同様の概念が存在します。

データベースシステムのセットアップ

現在のほとんどのデータベースシステムは、CI 環境と開発者マシンの両方に簡単にインストールできます。多くの場合、通常のインストールメカニズムを使用してデータベースをインストールするのは簡単ですが、ほとんどの主要なデータベースにはすぐに使用できる Docker イメージが用意されており、CI でのインストールが特に簡単になります。開発者環境である GitHub Workspaces 用に、データベースを含む必要なすべてのサービスと依存関係を Dev Container で設定できます。これには最初にセットアップの手間が必要ですが、一度行えばテスト作業環境ができ上がり、より重要なことに集中できます。

場合によっては、データベースにはテストに役立てることができる特別なエディションまたはバージョンがあります。 SQL Server を使用する場合は、LocalDB を使用すると、実質的にセットアップなしでテストをローカルで実行し、必要に応じてデータベースインスタンスを起動して、あまり高性能ではない開発者マシンでリソースを節約できます。ただし、LocalDB に問題がないわけではありません。

これでは、SQL Server Developer エディションがサポートするものをすべてサポートしていません。
Windows でのみ使用できます。
サービスの起動後の最初のテスト実行では、遅延が発生する可能性があります。

通常は、LocalDB よりも SQL Server Developer エディションをインストールすることをお勧めします。SQL Server の完全な機能セットを備え、概してかなり簡単に実行できるからです。

クラウドデータベースを使用する場合は、通常、速度向上とコスト削減の両方のために、データベースのローカルバージョンに対してテストすることが適切です。たとえば、運用環境で SQL Azure を使用する場合は、ローカルにインストールした SQL Server に対してテストできます。これら 2 つは非常に似ています (ただし、運用に移行する前に SQL Azure 自体に対してテストを実行することをお勧めします)。 Azure Cosmos DB を使用する場合、Azure Cosmos DB エミュレーターは、ローカルでの開発とテスト実行の両方に役立つツールです。

テストデータベースの作成、シード処理、管理

データベースをインストールしたら、テストでの使用を開始する準備が整います。ほとんどのシンプルなケースの場合、テストスイートに含まれるデータベースは 1 つであり、それが複数のテストクラス間で共有されています。そのため、データベースがテスト実行の有効期間中に 1 回だけ作成およびシード処理されることを確実にするために、何らかのロジックが必要です。

Xunit を使用する場合は、これを行うためにクラスフィクスチャを使用できます。これはデータベースを表すものであり、複数のテスト実行で共有されます。

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

    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);
}

最後に、上記のフィクスチャの作成ロジックに含まれるロック処理に気付いたかもしれません。フィクスチャが 1 つのテストクラスだけで使用されている場合は、xUnit によって確実に 1 回だけそのインスタンスが作成されます。ただし、同じデータベースフィクスチャを複数のテストクラスで使用することが一般的です。 xUnit にはコレクションフィクスチャが用意されていますが、そのメカニズムを使用すると、テストのパフォーマンスにとって重要な、テストクラスの並列での実行ができません。これを xUnit クラスフィクスチャで安全に管理するために、データベースの作成とシード処理に簡単なロックを適用し、静的フラグを使用して、2 回行う必要がないようにしています。

データを変更するテスト

上記の例では、読み取り専用テストが示されています。これは、テストの分離の観点から見ると簡単なケースです。何も変更されないため、テストの干渉が起こり得ないからです。これに対し、データを変更するテストは相互に干渉する可能性があるため、より問題が生じやすくなります。書き込みテストを分離する一般的な手法の 1 つは、テストをトランザクションでラップし、テストの最後にそのトランザクションをロールバックすることです。実際にはデータベースには何もコミットされないため、他のテストでは変更は認識されず、干渉は回避されます。

次に示すのは、データベースにブログを追加するコントローラーメソッドです。

[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 でクリアして、以下のデータベースからブログが実際に読み込まれるようにします。代わりに 2 つのコンテキストインスタンスを使用することもできますが、そうした場合は、両方のインスタンスで確実に同じトランザクションが使用されるようにする必要があります。
フィクスチャの CreateContext でトランザクションを開始して、既にトランザクションに存在し、更新の準備ができているコンテキストインスタンスをテストで受け取るようにすることもできます。これは、トランザクションが誤って忘れられ、デバッグが困難なテストの干渉につながるケースを防ぐのに役立ちます。また、読み取り専用テストと書き込みテストを異なるテストクラスに分離することもできます。

トランザクションを明示的に管理するテスト

さらなる難しさを伴う最後のテストカテゴリが 1 つあります。データを変更し、かつトランザクションを明示的に管理するテストです。通常、入れ子になったトランザクションはデータベースでサポートされていないため、実際の製品コードで使用する必要があり、上記のように分離のためにトランザクションを使用することはできません。これらのテストはまれにしかない傾向にありますが、特別な方法で処理する必要があります。各テストの後にデータベースを元の状態にクリーンアップし、これらのテストが相互に干渉しないように並列処理を無効にする必要があります。

例として次のコントローラーメソッドを確認してみましょう。

[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";

    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 メソッドが含まれていることに注目してください。すべてのテストの後にこれを呼び出して、データベースが開始時の状態にリセットされるようにします。

このフィクスチャが 1 つのテストクラスでのみ使用される場合は、上記のようにクラスフィクスチャとして参照できます。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 はコレクションフィクスチャのインスタンス作成を 1 回だけ行うため、前述のようにデータベースの作成とシード処理に関するロックを使用する必要はありません。

上記の完全なサンプルコードはここで確認できます。

ヒント

データベースを変更するテストを含む複数のテストクラスがある場合も、それぞれ専用のデータベースを参照する別々のフィクスチャを使用して並列で実行できます。多数のテストデータベースを作成して使用することは問題ではなく、そうすることが役に立つ場合は、そうしてください。

効率的なデータベース作成

上記のサンプルでは、最新のテストデータベースを確実に使用するために、テストを実行する前に 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 パッケージの使用を検討することもできます。さらに、クリアする対象のテーブルを指定する必要がないため、モデルにテーブルを追加するときにクリーンアップコードを更新する必要はありません。

まとめ

実際のデータベースに対してテストする場合は、次のテストカテゴリを区別することをお勧めします。
- 読み取り専用テストは比較的単純であり、分離について気にすることなく、常に同じデータベースに対して並列で実行できます。
- 書き込みテストはそれよりも問題になりやすいものの、トランザクションを使用して、適切な分離を確実に行うことができます。
- トランザクションテストは最も問題が生じやすく、データベースを元の状態に戻すロジックと、並列処理を無効にすることが必要になります。
これらのテストカテゴリを別々のクラスに分離すると、テスト間での混乱や偶発的な干渉を回避できます。
シード処理されたテストデータを事前に考え、そのシードデータが変更されてもあまり頻繁に中断されないようにテストを記述するようにします。
複数のデータベースを使用して、データベースを変更するテストを並列処理し、場合によっては異なるシードデータ構成を使用できるようにすることもできます。
テスト速度が問題になる場合は、テストデータベースを作成し、実行のたびにデータをクリーンするための、より効率的な手法を検討することをお勧めします。
常にテストの並列処理と分離に留意してください。

運用データベースシステムに対するテスト

データベースシステムのセットアップ

テストデータベースの作成、シード処理、管理

データを変更するテスト

トランザクションを明示的に管理するテスト

効率的なデータベース作成

効率的なデータベースクリーンアップ

まとめ

フィードバック

その他のリソース

運用データベース システムに対するテスト

データベース システムのセットアップ

テスト データベースの作成、シード処理、管理

データを変更するテスト

トランザクションを明示的に管理するテスト

効率的なデータベース作成

効率的なデータベース クリーンアップ

まとめ

フィードバック

その他のリソース

運用データベースシステムに対するテスト

データベースシステムのセットアップ

テストデータベースの作成、シード処理、管理

効率的なデータベースクリーンアップ