Goのテストでseedingする #Go

Gopher道場 Advent Calendar 16日目のエントリです。
昨日は @kaznishi さんによる[豆知識]Bounds Check Eliminationでした。

Database周りの実装はテストでモックせずに、ちゃんとDBを使ってseedingしてテストしたくなります。
rubenv/sql-migrateを使って、migrationとseedingをいい感じに共存させる方法をご紹介します。

ちなみにdatastoreの場合はtimakin/dsmockが便利です。

ディレクトリ構造

まずmigrationとseedingをディレクトリ別々で作り、SQLを書いていきます。
他の言語のフレームワークを触ってるとよく出会う構成ですね。

./sql
├── migrations
│   └── 1.sql
└── testdata
    └── 1_test.sql

migrationをしたいときはmigrationsだけを、migrationとseedingを両方やるときは両方のディレクトリをがっちゃんこすればいい、という考え方です。

実装

Go製のmigrationツールはいくつかありますが、rubenv/sql-migrateを選んだ理由はmigrationファイルを柔軟にわたすことができるからです。

こちらがmigrationを実行する関数です。

// Execute a set of migrations
//
// Returns the number of applied migrations.
func Exec(db *sql.DB, dialect string, m MigrationSource, dir MigrationDirection) (int, error) {
    return ExecMax(db, dialect, m, dir, 0)
}

MigrationSourceはInterfaceとなっていて、FindMigrations()が実装されていればよい。

type MigrationSource interface {
    // Finds the migrations.
    //
    // The resulting slice of migrations should be sorted by Id.
    FindMigrations() ([]*Migration, error)
}

ちなみにrubenv/sql-migrateが標準で用意しているFileMigrationSource、HttpFileSystemMigrationSource、MemoryMigrationSourceなどのstructたちはFindMigrations()の振る舞いを持っています。

ということは、複数のFindMigrations()をがっちゃんこするFindMigrations()を実装すれば、複数ディレクトリを指定できるはず・・・！

type migrationSources struct {
    sources []migrate.MigrationSource
}

func (mss *migrationSources) FindMigrations() ([]*migrate.Migration, error) {
    var migrations []*migrate.Migration

    for _, s := range mss.sources {
        ms, err := s.FindMigrations()
        if err != nil {
            return nil, err
        }
        migrations = append(migrations, ms...)
    }

    return migrations, nil
}

migrationSourcesに./sql/migrationsと./sql/testdataが合わさってmigrationが走ります。

    mc := &migrationSources{
        sources: []migrate.MigrationSource{
            &migrate.FileMigrationSource{
                Dir: "./sql/migrations",
            },
            &migrate.FileMigrationSource{
                Dir: "./sql/testdata",
            },
        },
    }

    _, err = migrate.Exec(db, "postgres", mc, migrate.Up)

これをdatabaseを使うテストに挟んであげると、ケースごとにまっさらな状態にテストできます。
参照系のテストであれば、ケースごとではなくていいと思います。

    for name, c := range cases {
        t.Run(name, func(t *testing.T) {
            migrateUp(t)
            defer migrateDown(t)

            // ...
        })
    }

デメリット

DBのmigrationテーブルを見てみると、本来入るべきではないseedingのファイルが入ってしまいます。
が、テスト時だけなら、毎回、migrationをゼロから実行するので問題はなさそうです。

SELECT * FROM gorp_migrations;
     id     |          applied_at
------------+-------------------------------
 1.sql      | 2018-12-12 14:00:05.608612+00
 1_test.sql | 2018-12-12 14:00:05.610527+00

まとめ

rubenv/sql-migrateはmigrationライブラリながらも工夫をすれば、テスト時のseedingにも使える。ただし、seedingのファイル名もmigrationテーブルに記録されてしまうので、アプリケーションを動かすときのseedingには向かない。

サンプルコードはこちら
https://github.com/sawadashota/sql-test-sample

明日は @mizkei さんのエントリになります。お楽しみに！