GitHub Actions のワークフロー内で Microsoft SQL Server データベースを読み書きする単体テストを実行する

本物の SQL Server データベースに読み書きする単体テスト

極めて希なケースだとは思うのだが、とある単体テストプログラム内で、やむなく、実際の MS SQL Sever データベースに対する読み書きを行なうテストを実装した。

自分の開発環境は Windows OS なので、その開発環境に SQL Server LocalDB がインストールされていることを要件として、SQL Server LocalDB に接続してデータベースを作っては読み書きを実行して、最後にはその作ったデータベースを破棄する、そんな単体テストプログラムとなっている。

実装は C# で、データベースを読み書きするライブラリには Entity Framework Core を採用、Code First スタイルで実装した。

Code First スタイルなので、データベース構造は C# コードで表現されているから、単体テストプログラム自身によって使い捨てデータベースをその場で構築できるという仕掛けだ。

構築するデータベース名は、どうせ使い捨てなので毎回 GUID 値で生成して構築し、テストの並列実行にも耐えられるようにはしている。

ちなみに、大抵の場合は、実際のデータベースエンジンに接続して読み書きする程のことを、単体テストのレベルで実装する必要は発生しないはずだ。

単体テストでホンモノのデータベースエンジンに接続して読み書きするのは、単体テストの実行にかかる時間も伸びるし、原則悪手である。

あるいはどうしてもリアルなデータベースに読み書き必須という場合であっても、必ずしも SQL Server ではなくて、SQLite のインメモリーデータベースを使えばそれで済むことも多い。
SQLite のインメモリーデータベースなら処理速度も速いし、破棄も簡単だ。
もちろん、SQL Server と SQLite はまったくの別モノなので、互換性の問題もないわけではない。
とはいえ、単体テストのレベルでは、その互換性が問題にならないことも多いと思う。

しかしながら、自分の境遇では、どうしても SQL Server じゃなきゃいけない、且つ、単体テストとして実装したい、という必要に迫られていた。
それで、上記のように実装した次第。

それ、GitHub Actions のワークフロー内で実行できる?

と、ここまではよいのだが、ひとつ困ったことがあった。

この単体テストプログラム、実行環境に SQL Server が事前インストールされていることが実行の必要要件なので、そのままでは GitHub Actions のワークフロー内で実行できないのだ。

手段がないわけではない。

Microsoft SQL Server は Windows OS 上だけでなく、Linux 上でも動作するエディションがある。
および、Docker イメージも公開されている。

例えば、下記のように docker コマンドを実行すれば、インターネット上から SQL Server 2019 の Docker イメージをダウンロードして、Docker コンテナとして実行してくれる。

$ docker run -e "ACCEPT_EULA=Y" \
    -e "SA_PASSWORD=Passw0rd" \
    -p 1433:1433 \
    --name sql1 \
    --hostname sql1 \
    -d mcr.microsoft.com/mssql/server:2019-latest

上記の例だと、 docker コマンド実行時のコマンドライン引数に見えているが、待ち受けの TCP ポート番号は 1433、認証は SQL 認証で既定の管理アカウント "sa" のパスワードとして "Passw0rd" で起動する。

こうして、ひとたび SQL Server の Docker コンテナが起動したら、同一 PC 上であれば、以下のような sqlcmd コマンドで接続して任意の SQL 文を実行できるようになるはずだ。

$ sqlcmd -S localhost,1433 -U sa -P Passw0rd

実のところ、これらのことは、インターネット上で検索するとたくさんの解説記事がヒットする。
Microsoft の公式ドキュメントサイトのリンク先は下記。

さらに幸いなことに、GitHub Actions ワークフロー内からも、docker コマンドを使って Docker コンテナを起動できるとのこと。

そこで、今回の単体テストプログラムを収録している GitHub リポジトリにて、上記 docker コマンドの実行をワークフロー内に記述して、単体テストプログラムを実行するように構成してみた。

単体テストプログラムは、環境変数の指定を見て接続先の SQL Server を判断するようにし、および、ワークフロー定義内でそれら必要な環境変数を事前設定するようにした。

ちなみに、データベース接続文字列は以下のようになる。

"Server=localhost,1433;User=sa;Password=Passw0rd;TrustServerCertificate=True;"

C# プログラム内から、上記データベース接続文字列で SQL Server に接続すれば、カレントデータベースを master データベースとして、Docker コンテナとして起動した SQL Server に接続できるはずだ。

なお、ちょっと注意すべきは、上記データベース接続文字列中の "TrustServerCertificate=True;" の指定。
これがないと、下記例外が発生することがある。

Microsoft.Data.SqlClient.SqlException : A connection was successfully

established with the server, but then an error occurred during the

pre-login handshake. (provider: TCP Provider, error: 35 - An internal

exception was caught)

---- System.Security.Authentication.AuthenticationException : The

remote certificate was rejected by the provided

RemoteCertificateValidationCallback.

Docker コンテナで実行された、隔離された SQL Server なので、コンテナの外側と何かしら証明書の同期で問題があるのだろう。

今回はあくまでも単体テストプログラムの実行のために、使い捨てデータベースを構築して利用してすぐに破棄するだけである。
なので、上記 "TrustServerCertificate=True;" の指定をデータベース接続文字列に記載して、サーバー証明書を問答無用で信用することで回避とした。

以上の手筈を整えて、上記構成で GitHub Actions ワークフローを実行した結果、無事に単体テストプログラムが実行された。

おわりに

以上、docker コマンド実行のたった 1行を GitHub Actions のワークフロー定義に書き足すだけで、ホンモノの SQL Server データベースに読み書きするテストを GitHub Actions 上で実行できてしまった。

あまりにあっけなくできたので、拍子抜けした。

実際のワークフロー定義は下記リンク先で見られる。

単体テストプログラム (C#) も、同リポジトリ内で見つけられるはずだ。

ただし、この GitHub Actions ワークフロー、SQL Server の Docker イメージのダウンロードとコンテナ起動にも結構時間を取られるし (自分の観測範囲ではおおよそ 20秒ほどかかっている)、そもそも SQL Server データベースにリアルに読み書きするテストそれ自体もものすごく時間を食う (自分の例では 2分近く実行にかかっている)。

このようなやり方を強くお勧めするものではないので、その点はくれぐれも承知しておいて頂きたい。