1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 11

ZOZO Advent Calendar 2025

Day 14

Java Advent Calendar 2025

@seijikohara(Seiji Kohara)in株式会社ZOZO

[JUnit/Spock/Kotest] DB Tester: アノテーションとCSVでデータ投入から検証まで完結するDBテストフレームワーク (Spring Boot対応)

Last updated at Posted at 2025-12-10

はじめに

データベースを利用するアプリケーションのテストでは、テストデータの準備、テスト後の状態検証、複数テストケース間でのデータ分離など、考慮すべき事項が多くあります。

筆者自身、これらの作業を繰り返す中で「アノテーションを付けるだけでCSVからデータを投入し、結果を検証できれば便利なのでは」と考え、JUnit、Spock、Kotestに対応したデータベーステストフレームワーク「DB Tester」を作成しました。本記事では、このライブラリの機能と使い方を紹介します。

特徴

Convention over Configuration

テストクラス名・パッケージ名に基づいてCSVファイルを自動的に解決します。明示的なパス指定は不要です。

src/test/resources/
└── com/example/UserRepositoryTest/
    ├── USERS.csv              # @DataSetで読み込まれる
    └── expected/
        └── USERS.csv          # @ExpectedDataSetで比較される

宣言的なテスト記述

@DataSetと@ExpectedDataSetアノテーションを付与するだけで、テストデータの準備と検証を行います。アノテーションはクラスレベルまたはメソッドレベルに付与できます。

@ExtendWith(DatabaseTestExtension.class)
@DataSet  // 全テストメソッドに適用
@ExpectedDataSet
class UserRepositoryTest {

    @Test
    void shouldCreateUser() {
        userRepository.create(new User("john", "john@example.com"));
    }

    @Test
    @DataSet(operation = Operation.INSERT)  // このメソッドのみ上書き
    void shouldUpdateUser() {
        userRepository.update(new User(1, "updated", "updated@example.com"));
    }
}

シナリオベースのテスト

[Scenario]列を使用して、1つのCSVファイルから複数のテストケースに対応するデータを抽出できます。テストメソッド名がシナリオ名として使用されます。

[Scenario],ID,NAME,EMAIL
shouldCreateUser,1,existing,existing@example.com
shouldUpdateUser,1,target,target@example.com
shouldDeleteUser,1,delete_me,delete@example.com

プログラマティックAPI

アノテーションベースの検証に加えて、テスト中に任意のタイミングでデータベースの状態を検証できます。特定のカラムを無視した比較や、SQLクエリ結果の検証、カラムごとの比較戦略が設定可能です。

// 特定カラムを無視して比較
DatabaseAssertion.assertEqualsIgnoreColumns(
    expectedTableSet, actualTableSet, "USERS", "CREATED_AT", "UPDATED_AT");

// SQLクエリ結果を検証
DatabaseAssertion.assertEqualsByQuery(
    expectedTableSet, dataSource, "USERS",
    "SELECT * FROM USERS WHERE STATUS = 'ACTIVE'");

// カラムごとの比較戦略を使用
DatabaseAssertion.assertEqualsWithStrategies(expectedTable, actualTable,
    ColumnStrategyMapping.ignore("CREATED_AT"),
    ColumnStrategyMapping.caseInsensitive("EMAIL"),
    ColumnStrategyMapping.regex("TOKEN", "[a-f0-9-]{36}"));

複数DataSource対応

1つのテストで複数のデータベースに対する操作と検証が可能です。

@BeforeAll
static void setUp(ExtensionContext context) {
    DataSourceRegistry registry = DatabaseTestExtension.getRegistry(context);
    registry.registerDefault(primaryDataSource);
    registry.register("secondary", secondaryDataSource);
}

@Test
@DataSet(sources = @DataSetSource(dataSourceName = "secondary"))
void shouldUseSecondaryDatabase() {
    // secondaryデータベースに対するテスト
}

他のフレームワークとの比較

Javaにはデータベーステスト用のフレームワークがいくつか存在します。ここでは主要なフレームワークとDB Testerを比較します。

比較表

機能 DB Tester DBUnit Database Rider DbSetup
データ形式 CSV/TSV XML/CSV/Excel XML/JSON/YAML/CSV Fluent API
アノテーション @DataSet/@ExpectedDataSet なし @DataSet/@ExpectedDataSet なし
規約ベース検出 あり なし なし なし
シナリオフィルタリング あり なし なし なし
テスト後の検証 組み込み 別途実装が必要 組み込み なし
JUnit 6サポート あり なし なし なし
Spockサポート ネイティブ 別途統合が必要 あり なし
Kotestサポート ネイティブ なし なし なし
Spring Boot Starter あり なし あり なし
JPMS対応 あり なし なし なし
外部依存 なし（Pure JDBC） 多数 DBUnit依存 少数
Java 21+ 完全対応 部分的 部分的 対応

DBUnit

DBUnitはJavaで最も歴史のあるデータベーステストフレームワークです。

DBUnitの特徴:

  • XMLベースのデータセット（FlatXmlDataSet）が主流
  • 豊富なデータベース操作（CLEAN_INSERT、REFRESH等）
  • 広範なドキュメントとコミュニティ

DB Testerとの違い:

// DBUnit: XMLファイルとプログラマティックなセットアップが必要
@Before
public void setUp() throws Exception {
    IDatabaseConnection connection = new DatabaseConnection(dataSource.getConnection());
    IDataSet dataSet = new FlatXmlDataSetBuilder()
        .build(new FileInputStream("src/test/resources/dataset.xml"));
    DatabaseOperation.CLEAN_INSERT.execute(connection, dataSet);
}

// DB Tester: アノテーション1つで完了
@Test
@DataSet
void testMethod() { }

DBUnitは機能豊富ですが、XMLの冗長さとボイラープレートコードの多さが課題です。また、JUnit 5/6のExtension APIにネイティブ対応していないため、別途統合が必要です。

Database Rider

Database RiderはDBUnitをベースに、CDI/JUnit統合とアノテーションAPIを追加したフレームワークです。

Database Riderの特徴:

  • DBUnitの機能をアノテーションで利用可能
  • YAML/JSONなどモダンなデータ形式をサポート
  • CDI（Contexts and Dependency Injection）との統合

DB Testerとの違い:

// Database Rider
@Test
@DataSet(value = "users.yml", cleanBefore = true)
@ExpectedDataSet(value = "expected-users.yml")
void testMethod() { }

// DB Tester: 規約ベースでファイルパス指定が不要
@Test
@DataSet
@ExpectedDataSet
void testMethod() { }

Database RiderはDBUnitに依存しているため、DBUnitの制約（古い依存関係、JUnit 4ベースの設計）を継承しています。また、JUnit 6やKotestのネイティブサポートはありません。

DbSetup

DbSetupはFluent APIでテストデータを定義するライブラリです。

DbSetupの特徴:

  • Javaコードでデータを定義（型安全）
  • 軽量で依存関係が少ない
  • シンプルな設計

DB Testerとの違い:

// DbSetup: Javaコードでデータを定義
@Before
public void setUp() {
    Operation operation = sequenceOf(
        deleteAllFrom("USERS"),
        insertInto("USERS")
            .columns("ID", "NAME", "EMAIL")
            .values(1, "john", "john@example.com")
            .values(2, "jane", "jane@example.com")
            .build()
    );
    DbSetup dbSetup = new DbSetup(new DataSourceDestination(dataSource), operation);
    dbSetup.launch();
}

// DB Tester: CSVファイルでデータを定義
// USERS.csv
// ID,NAME,EMAIL
// 1,john,john@example.com
// 2,jane,jane@example.com

DbSetupはFluent APIによる型安全性がメリットですが、大量のテストデータを扱う場合はコードが冗長になります。また、テスト後の状態検証機能がないため、別途アサーションを実装する必要があります。

選択の指針

ユースケース 推奨フレームワーク
新規プロジェクト（Java 21+） DB Tester
既存のDBUnit資産を活用したい Database Rider
型安全なデータ定義が必要 DbSetup
レガシーJavaプロジェクト DBUnit
Spock/Kotestを使用 DB Tester
シナリオベースのテスト DB Tester

DB Testerの優位点

  1. 規約ベースの自動検出: ファイルパスの明示的な指定が不要
  2. シナリオフィルタリング: 1つのCSVファイルで複数テストケースに対応
  3. モダンJavaサポート: Java 21、JPMS、JUnit 6に完全対応
  4. マルチフレームワーク: JUnit、Spock、Kotestをネイティブサポート
  5. Pure JDBC: 外部テストフレームワークへの依存がなく、軽量
  6. 可読性の高いエラーメッセージ: YAML形式で差分を出力

インストール

Gradle

build.gradle.kts
testImplementation(platform("io.github.seijikohara:db-tester-bom:VERSION"))
testImplementation("io.github.seijikohara:db-tester-junit")

Maven

pom.xml
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.github.seijikohara</groupId>
            <artifactId>db-tester-bom</artifactId>
            <version>${db-tester.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependency>
    <groupId>io.github.seijikohara</groupId>
    <artifactId>db-tester-junit</artifactId>
    <scope>test</scope>
</dependency>

モジュール選択

ユースケース モジュール
JUnit db-tester-junit
JUnit + Spring Boot db-tester-junit-spring-boot-starter
Spock db-tester-spock
Spock + Spring Boot db-tester-spock-spring-boot-starter
Kotest db-tester-kotest
Kotest + Spring Boot db-tester-kotest-spring-boot-starter

基本的な使用方法

1. テストクラスの作成

UserRepositoryTest.java
@ExtendWith(DatabaseTestExtension.class)
@DataSet  // クラス内の全テストメソッドに適用
@ExpectedDataSet
class UserRepositoryTest {

    @BeforeAll
    static void setUp(ExtensionContext context) {
        DataSource dataSource = createDataSource();
        DatabaseTestExtension.getRegistry(context).registerDefault(dataSource);
    }

    @Test
    void shouldCreateUser() {
        userRepository.create(new User("john", "john@example.com"));
    }

    @Test
    void shouldUpdateUser() {
        userRepository.update(new User(1, "updated", "updated@example.com"));
    }
}

2. CSVファイルの作成

[Scenario]列でテストメソッドごとにデータを分離します。

USERS.csv
[Scenario],ID,NAME,EMAIL
shouldCreateUser,1,existing,existing@example.com
shouldUpdateUser,1,target,target@example.com
expected/USERS.csv
[Scenario],ID,NAME,EMAIL
shouldCreateUser,1,existing,existing@example.com
shouldCreateUser,2,john,john@example.com
shouldUpdateUser,1,updated,updated@example.com
  • shouldCreateUserテスト: 既存ユーザー1件の状態から、新規ユーザーを作成し、2件になることを検証
  • shouldUpdateUserテスト: ユーザー1件の状態から、そのユーザーを更新し、更新後の値を検証

アノテーション

@DataSet

テスト実行前にCSVデータをデータベースに投入します。

属性 説明 デフォルト値
sources 適用するデータセットの配列 空（規約ベースの検出）
operation データベース操作の種類 CLEAN_INSERT
tableOrdering テーブル処理順序の戦略 AUTO 
// クラスレベル: 全テストメソッドに適用
@DataSet
class UserRepositoryTest { ... }

// メソッドレベル: 特定のテストメソッドに適用
@Test
@DataSet(operation = Operation.INSERT)
void shouldCreateUser() { ... }

// データセットの明示的な指定
@DataSet(sources = @DataSetSource(
    resourceLocation = "data/users",
    scenarioNames = {"testCase1"}
))

@ExpectedDataSet

テスト実行後にデータベースの状態をCSVファイルと比較検証します。

属性 説明 デフォルト値
sources 検証するデータセットの配列 空（規約ベースの検出）
tableOrdering テーブル処理順序の戦略 AUTO
rowOrdering 行比較戦略 ORDERED
retryCount 検証のリトライ回数 -1（グローバル設定を使用）
retryDelayMillis リトライ間隔（ミリ秒） -1（グローバル設定を使用） 
// クラスレベル: 全テストメソッドに適用
@ExpectedDataSet
class UserRepositoryTest { ... }

// メソッドレベル: 特定のテストメソッドに適用
@Test
@ExpectedDataSet(tableOrdering = TableOrderingStrategy.ALPHABETICAL)
void shouldCreateUser() { ... }

// 行順序を無視した比較
@ExpectedDataSet(rowOrdering = RowOrdering.UNORDERED)
void testWithUnorderedComparison() { ... }

// リトライ付き検証（非同期処理のテストに有用）
@ExpectedDataSet(retryCount = 3, retryDelayMillis = 500)
void testWithRetry() { ... }

両アノテーションは@Inheritedが付与されているため、サブクラスにも継承されます。共通のテスト設定を基底クラスに定義することで、コードの重複を削減できます。

@DataSetSource

データセットの詳細な設定を行います。

属性 説明
resourceLocation データセットディレクトリのパス
scenarioNames 適用するシナリオ名
dataSourceName 対象のDataSource名
excludeColumns 検証から除外するカラム名（@ExpectedDataSetでのみ有効）
columnStrategies カラムごとの比較戦略（@ExpectedDataSetでのみ有効）
リソース指定の形式
形式 例 説明
クラスパス相対 data/users テストクラスパスからの相対パス
クラスパスプレフィックス classpath:data/users 明示的なクラスパス解決
絶対パス /tmp/testdata ファイルシステムの絶対パス
空文字列 "" 規約ベースの自動検出（デフォルト）

カラム除外

タイムスタンプや自動生成IDなど、検証から除外したいカラムを指定できます。

データセットごとの除外:

@Test
@DataSet
@ExpectedDataSet(sources = @DataSetSource(
    excludeColumns = {"CREATED_AT", "UPDATED_AT", "VERSION"}
))
void testWithExcludedColumns() {
    userRepository.create(new User("john", "john@example.com"));
}

グローバル除外:

@BeforeAll
static void setUp(ExtensionContext context) {
    var config = Configuration.builder()
        .conventions(ConventionSettings.builder()
            .globalExcludeColumns(Set.of("CREATED_AT", "UPDATED_AT"))
            .build())
        .build();
    DatabaseTestExtension.setConfiguration(context, config);
    DatabaseTestExtension.getRegistry(context).registerDefault(dataSource);
}

カラム比較戦略

カラムごとに異なる比較ロジックを適用できます。

戦略 説明
STRICT equals()を使用した完全一致（デフォルト）
IGNORE 比較を完全にスキップ
NUMERIC BigDecimalを使用した型を考慮した数値比較
CASE_INSENSITIVE 大文字小文字を区別しない文字列比較
TIMESTAMP_FLEXIBLE UTCに変換しサブ秒精度を無視
NOT_NULL 値がnullでないことを検証
REGEX 正規表現を使用したパターンマッチング 
@ExpectedDataSet(sources = @DataSetSource(
    columnStrategies = {
        @ColumnStrategy(name = "EMAIL", strategy = Strategy.CASE_INSENSITIVE),
        @ColumnStrategy(name = "CREATED_AT", strategy = Strategy.IGNORE),
        @ColumnStrategy(name = "TOKEN", strategy = Strategy.REGEX, pattern = "[a-f0-9-]{36}")
    }
))
void testWithColumnStrategies() { }

データベース操作

@DataSetのoperation属性で指定できる操作の一覧です。

操作 説明 ユースケース
NONE 操作なし 読み取り専用の検証
INSERT 新規行を挿入 空テーブルへの追加
UPDATE 主キーで既存行を更新 既存データの変更
UPSERT Upsert（更新または挿入） 混合シナリオ
DELETE 主キーで指定行を削除 選択的な削除
DELETE_ALL 全行削除 シーケンスを保持したクリア
TRUNCATE_TABLE テーブルをTruncate シーケンスリセット付きクリア
CLEAN_INSERT 全削除後に挿入（デフォルト） 標準的なテスト準備
TRUNCATE_INSERT Truncate後に挿入 シーケンスリセット付きセットアップ

データファイル形式

CSVとTSVの2つの形式をサポートしています。

形式 拡張子 区切り文字 デフォルト
CSV .csv カンマ (,) Yes
TSV .tsv タブ (\t) No

形式の切り替えはConventionSettingsで設定します:

var config = Configuration.builder()
    .conventions(ConventionSettings.builder()
        .dataFormat(DataFormat.TSV)
        .build())
    .build();

基本構造

1行目はヘッダー行として扱われます。[Scenario]列はシナリオフィルタリングに使用されます。

[Scenario],ID,NAME,EMAIL,CREATED_AT
shouldCreateUser,1,john,john@example.com,2024-01-01 10:00:00

データ型の表現

表現 意味
空フィールド NULL値
空のクォート ("") 空文字列
2024-01-01 日付型（DATE）
2024-01-01 10:00:00 タイムスタンプ型（TIMESTAMP）
true / false 真偽値（BOOLEAN）
Base64文字列 BLOB型 
ID,NAME,DESCRIPTION,CREATED_AT,IS_ACTIVE
1,test,,2024-01-01 10:00:00,true
2,empty,"",2024-01-01 11:00:00,false

上記の例では:

  • 1行目のDESCRIPTIONはNULL
  • 2行目のDESCRIPTIONは空文字列

テーブル処理順序

外部キー制約を考慮して、テーブルの処理順序を制御できます。

TableOrderingStrategy

@DataSetおよび@ExpectedDataSetのtableOrdering属性で順序決定の戦略を指定できます。

戦略 説明
AUTO 自動決定（デフォルト）
LOAD_ORDER_FILE load-order.txtを使用（必須）
FOREIGN_KEY JDBCメタデータで外部キー依存関係を解決
ALPHABETICAL テーブル名でアルファベット順にソート

AUTO戦略では以下の優先順位で順序を決定します:

  1. load-order.txtが存在する場合はそれを使用
  2. JDBCメタデータから外部キー依存関係を解決
  3. アルファベット順にフォールバック

外部キー自動解決

DB Testerはデータベースメタデータから外部キー関係を自動的に取得し、テーブルの処理順序を決定します。親テーブル（参照される側）が子テーブル（外部キーを持つ側）より先に処理されるため、外部キー制約違反を防ぐことができます。

この機能はJDBCのDatabaseMetaData.getExportedKeys()を使用して実装されており、特別な設定は不要です。

循環参照が検出された場合は警告をログに出力し、データセット宣言順が維持されます。

load-order.txt

データセットディレクトリにload-order.txtを配置することで、テーブルの処理順序を明示的に指定できます。

load-order.txt
# 親テーブルを先に記述
USERS
CATEGORIES

# 子テーブルは親テーブルの後に記述
ORDERS
ORDER_ITEMS

load-order.txtが存在しない場合、自動生成は行われません。明示的に必要な場合はTableOrderingStrategy.LOAD_ORDER_FILEを指定してください（ファイルが見つからない場合はエラーになります）。

操作別の処理順序
操作 処理順序
INSERT, UPSERT 親テーブル → 子テーブル（順方向）
DELETE, DELETE_ALL 子テーブル → 親テーブル（逆順）
TRUNCATE_TABLE 子テーブル → 親テーブル（逆順）
CLEAN_INSERT DELETE（逆順）→ INSERT（順方向）
TRUNCATE_INSERT TRUNCATE（逆順）→ INSERT（順方向）

フレームワーク統合

Spring Boot + JUnit

@SpringBootTest
@ExtendWith(SpringBootDatabaseTestExtension.class)
@DataSet
@ExpectedDataSet
class UserRepositoryTest {

    @Autowired
    private UserRepository userRepository;

    @Test
    void shouldCreateUser() {
        userRepository.save(new User("john", "john@example.com"));
    }
}

Spring Boot Starterを使用する場合、DataSourceは自動的に登録されます。

Spock Framework

Spock Frameworkでは@DatabaseTestアノテーションを使用して拡張機能を有効化します。DatabaseTestSupportトレイトを実装する必要があります。

UserRepositorySpec.groovy
@DatabaseTest
class UserRepositorySpec extends Specification implements DatabaseTestSupport {

    @Shared
    DataSource dataSource

    DataSourceRegistry dbTesterRegistry = new DataSourceRegistry()

    def setupSpec() {
        dataSource = createDataSource()
        dbTesterRegistry.registerDefault(dataSource)
    }

    @DataSet
    @ExpectedDataSet
    def "should create user"() {
        when:
        userRepository.create(new User("john", "john@example.com"))

        then:
        noExceptionThrown()
    }
}

Spock + Spring Boot

@SpringBootTest
@SpringBootDatabaseTest
class UserRepositorySpec extends Specification {

    @Autowired
    UserRepository userRepository

    @DataSet
    @ExpectedDataSet
    def "should create user"() {
        when:
        userRepository.save(new User("john", "john@example.com"))

        then:
        noExceptionThrown()
    }
}

Kotest

Kotest FrameworkではAnnotationSpecとDatabaseTestSupportインターフェースを使用します。

UserRepositorySpec.kt
@DatabaseTest
class UserRepositorySpec : AnnotationSpec(), DatabaseTestSupport {

    override val dbTesterRegistry = DataSourceRegistry()
    private lateinit var dataSource: DataSource

    @BeforeAll
    fun setupSpec() {
        dataSource = createDataSource()
        dbTesterRegistry.registerDefault(dataSource)
    }

    @Test
    @DataSet
    @ExpectedDataSet
    fun `should create user`() {
        userRepository.create(User("john", "john@example.com"))
    }
}

Kotest + Spring Boot

@SpringBootTest
class UserRepositorySpec : AnnotationSpec() {

    @Autowired
    private lateinit var userRepository: UserRepository

    init {
        extensions(SpringBootDatabaseTestExtension())
    }

    @Test
    @DataSet
    @ExpectedDataSet
    fun `should create user`() {
        userRepository.save(User("john", "john@example.com"))
    }
}

Spring Boot設定プロパティ

Spring Boot Starterを使用する場合、application.propertiesで設定をカスタマイズできます。

# DB Testerの有効化/無効化（デフォルト: true）
db-tester.enabled=true

# DataSource Beanの自動登録（デフォルト: true）
db-tester.auto-register-data-sources=true

# データフォーマット（CSVまたはTSV）
db-tester.convention.data-format=CSV

# 期待ディレクトリサフィックス
db-tester.convention.expectation-suffix=/expected

# シナリオマーカーカラム名
db-tester.convention.scenario-marker=[Scenario]

# グローバル除外カラム
db-tester.convention.global-exclude-columns=CREATED_AT,UPDATED_AT,VERSION

# デフォルト準備操作
db-tester.operation.preparation=CLEAN_INSERT

対応データベース

以下のデータベースで動作確認済みです。

  • H2
  • MySQL
  • PostgreSQL
  • Oracle
  • SQL Server
  • Apache Derby
  • HSQLDB

標準JDBCを使用しているため、JDBC対応のデータベースであれば動作します。

アサーションメッセージ

期待値の検証が失敗した場合、フレームワークはすべての差分を収集し、人間が読みやすい形式で報告します。

summary:
  status: FAILED
  total_differences: 3
tables:
  USERS:
    differences:
      - path: row_count
        expected: 3
        actual: 2
  ORDERS:
    differences:
      - path: "row[0].STATUS"
        expected: COMPLETED
        actual: PENDING
        column:
          type: VARCHAR(50)
          nullable: true
      - path: "row[1].AMOUNT"
        expected: 100.00
        actual: 99.99
        column:
          type: "DECIMAL(10,2)"

出力は有効なYAML形式のため、CI/CDパイプラインでの解析にも利用できます。

サンプルプロジェクト

GitHubリポジトリに各種サンプルが用意されています。

サンプル 説明
JUnit 基本的なJUnit統合
JUnit + Spring Boot Spring Boot環境でのJUnitテスト
Spock 基本的なSpock統合
Spock + Spring Boot Spring Boot環境でのSpockテスト
Kotest 基本的なKotest統合
Kotest + Spring Boot Spring Boot環境でのKotestテスト

サンプルコードはexamplesディレクトリを参照してください。

アーキテクチャ

DB Testerは、公開APIと内部実装を明確に分離した設計を採用しています。

モジュール 説明
db-tester-api 公開API（アノテーション、設定、SPI）
db-tester-core 内部実装（JDBC操作、CSVパーサー）
db-tester-spring-support Spring DataSource統合サポート
db-tester-junit JUnit Jupiter拡張
db-tester-spock Spock拡張
db-tester-kotest Kotest AnnotationSpec拡張
db-tester-*-spring-boot-starter Spring Boot統合
db-tester-bom Bill of Materials

JPMSを使用して、内部実装パッケージへのアクセスを制限しています。

動作要件

要件 バージョン
Java 21以上
JUnit 6（JUnit統合の場合）
Spock 2 + Groovy 5（Spock統合の場合）
Kotest 6 + Kotlin 2（Kotest統合の場合）
Spring Boot 4（Spring Boot統合の場合）

まとめ

DB Testerは、以下の利点を提供します。

  • ボイラープレートコードの削減 - アノテーションによる宣言的なテスト記述
  • 直感的なテスト定義 - CSVファイルによるテストデータの可視化
  • 柔軟なデータ管理 - シナリオフィルタリングによるテストデータの共有
  • 柔軟な検証 - カラム除外と比較戦略によるカスタマイズ可能な検証
  • 外部依存なし - Pure JDBC実装で外部テストフレームワークへの依存がない
  • フレームワーク対応 - JUnit、Spock、Kotest、Spring Bootとの統合

データベーステストの効率化に興味がある方は、ぜひ試してみてください。

関連リンク

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?