C#、ASP.NET、TypeScript、Angular を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
Entity Framewo..
at 2019-08-29 21:11
ASP.NET Core で..
at 2019-07-06 23:02
Azure Storage ..
at 2019-06-09 13:15
node のバージョンあげた..
at 2019-05-24 19:43
.NET HTTP REPL..
at 2019-04-23 00:19
最新のコメント
Windows Upda..
by mtakama at 12:06
同じ問題で悩んでいました..
by yonas at 12:32
Mac(Chrome)で..
by Macユーザー at 00:46
すみません、記事書きかけ..
by developer-adjust at 22:36
続きはないんですか?
by hanamo at 13:03
助かりました。ありがとう..
by あああ at 21:32
いえす、F#! F#! :)
by developer-adjust at 21:46
F#はAzure Not..
by 幻のK泉さん at 18:37
> 今、Setcronj..
by developer-adjust at 08:25
今、Setcronjob..
by Kibe at 03:23
記事ランキング
最新のトラックバック
Web API における..
from 松崎 剛 Blog
[Other]Code2..
from KatsuYuzuの日記
Developer @ ..
from .NET Clips
asp.netでrail..
from 4丁目より
F#でASP.NET M..
from ナオキにASP.NET(仮)
[B!] これはいい h..
from Twitter Mirror
[報告] Microso..
from .NET Clips
Developer @ ..
from .NET Clips
[F#]F# でブログア..
from 予定は未定Blog版
ASP.NET MVC ..
from ナオキにASP.NET(仮)
以前の記事
2019年 08月
2019年 07月
2019年 06月
2019年 05月
2019年 04月
2019年 03月
2019年 02月
2019年 01月
2018年 12月
2018年 11月
2018年 10月
2018年 09月
2018年 08月
2018年 07月
2018年 06月
2018年 05月
2018年 04月
2018年 03月
2018年 02月
2018年 01月
2017年 12月
2017年 11月
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 06月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 10月
2009年 09月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
ファン
ブログジャンル
画像一覧
2017年 12月 22日

EntityFramework Core を使ってデータベースを読み書きするプログラムの単体テストに In-Memory データベースを使ってみた

.NET プログラミングにおけるデータベースアクセスを担うライブラリ EntityFramework。

その EntityFramework の、.NET Core にも対応した新世代バージョンが EntityFramwork Core である。

EntityFrmework 及び EntityFrmework Core は、SQL Server 接続用や SQLite 接続用などの "データベースプロバイダ" を介して、実際のデータベースアクセスを行うプロバイダモデルとなっている。

そして EntityFramework Core には In-Memory データベースプロバイダが提供されている。

このデータベースプロバイダは、文字通り、メモリをデータ保存領域とした、すぐに揮発はしてしまうが高速に動作させることができるデータベースプロバイダである。
NuGet パッケージの説明書きにもあるように、もっぱらテスト用途を想定したデータベースプロバイダだ。

この In-Memory データベースプロバイダ、これまで実際に使ってみたことはなかったのだが、今回、機会を得たので、EntityFramework Core を用いたデータベースアクセスを伴うプログラムの単体テストに試用してみた。

実装の様子

下記のようなデータベースコンテキストクラスを実装していたとして、using Microsoft.EntityFrameworkCore;

public class MyDbContext : DbContext {
// ... ここに DbSet<T> 型のプロパティでエンティティ = テーブル を定義

// コンストラクタ
public MyDbContext(DbContextOptions<MyDbContext> options)
: base(options)
{
}
}
データベースコンテキストを、In-Memory データベースプロバイダの使用を指定して構築するには、下記のコードとなる。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseInMemoryDatabase(databaseName: "MyMemDb")
.Options;

var db = new MyDbContext(option);
db.Database.EnsureCreated();
上記コードの最終行、"EnsureCreated()" の呼び出しによって、データベースコンテキストクラスによって示されるモデルのとおりに、In-Memory データベースが構築される。

あとはこのデータベースコンテキストオブジェクトを通して、普通に EntityFramework によるデータベースアクセスのコードが実行できる。

実際に 1対多のリレーションを持つようなモデルで、
  • エンティティへの Add() や AddRaneg() からの SaveChanges() 、
  • そのあとの Where() や OrderBy() を伴う読み取り、
  • Include() によるイーガーローディング
などを動作確認してみたが、ちゃんと期待どおりに動作してくれた。

寿命はプロセス単位、名前が同じなら同じデータベースインスタンスを指す

In-Memory データベースプロバイダを使用する指定のところで、"データベース名" なるものを指定している(下記)。 .UseInMemoryDatabase(databaseName: "MyMemDb")これは In-Memory データベースのインスタンスに付与する名前だそうだ。

さすがに使える文字種など制約・規約はあると思うが、しかしそれは別にして、とにかくプログラマが好きな名前を指定してよい。

但し、同じデータベース名を引数に UseInMemoryDatabase() 呼び出しして得たデータベースコンテキストは、同じ "内容" のデータベースを読み書きすることになる。

また、この In-Memory のデータベースは、プロセスが生きている間は生存し続けているっぽい。

この仕組み・仕様をうまく活用すれば、テスト対象の In-Memory データベース常態の初期構築をいちどだけ実行する、といった、単体テスト処理速度のチューニングに使えるのかもしれない。

しかし、同じデータベースインスタンスをテスト実行期間の間、テスト間で共有し続けたら、各テストの前提条件と結果が入り乱れてテストにならないのではないだろうか。

そう考えると、テストごとに異なる In-Memory データベースインスタンスを割り当てたほうが良いのでは、と思った。

ちなみに、テストごとに異なる In-Memory データベースのインスタンスを割り当てる、すなわち別々の異なるデータベース名で初期化するには、自分がすぐに思いつくのは GUID 値を用いる方法である。 .UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())こうすることで、とりあえずテストごとに別々の In-Memory データベースインスタンスを使用するようになり、テスト間の干渉なく安心してテストを実装・実行できる。

ただ、いちど作られた In-Memory データベースインスタンスを明示的に破棄する方法があるのかないのか、現時点ではわかっていない。

そのため、テスト実行プロセスの期間中、実行されるテストによって次々と In-Memory データベースインスタンスが立てられ、テストによってレコードが追加され、しかし破棄されないとなると、メモリ消費量が大変なことになったりしないか、ちょっと心配である。

トランザクションは効かない

あと、In-Memory データベースプロバイダは、データベーストランザクションが使えない。

In-Memory データベースプロバイダを設定したデータベースコンテキストで、下記のとおり "BeginTransaction()" 呼び出しを実行すると、var t = db.Database.BeginTransaction();この呼び出しで

「System.InvalidOperationException : Warning as error exception for warning 'Microsoft.EntityFrameworkCore.Database.Transaction.TransactionIgnoredWarning': Transactions are not supported by the in-memory store.」

という例外が発生してしまう。

上記「In-Memory データベースはトランザクションをサポートしていません」警告を、例外とせずに無視するよう設定することもできる。

下記のとおり、オプション設定するところで "ConfigureWarnings()" 呼び出しを付け加え、上記警告を示す Event ID 値を無視するよう Ignore メソッドで指定する。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseInMemoryDatabase(databaseName: ...)

.ConfigureWarnings(opt => {
opt.Ignore(InMemoryEventId.TransactionIgnoredWarning);
})
.Options;
ただし、これで例外を発生することはなくなるが、In-Memory データベースがトランザクションをサポートしていないことには変わりないので注意が必要だ。

すなわち、トランザクションのロールバックが実行されても、データベース状態は巻き戻らず、すべての追加/変更は即座にコミット・反映されてしまう。

SQLite の In-Memory データベース

さてところで、EntityFramework Core で利用可能なデータベースプロバイダのひとつとして、SQLite 用データベースプロバイダがある。

そして、SQLite にも In-Memory データベース機能がある。

https://www.sqlite.org/inmemorydb.html

ということで、先述の EntityFramework Core ネイティブの In-Memory データベースプロバイダのときと同様に、単体テスト用途で、SQLite の In-Memory モードを使うこともできる。

データベースコンテキスト構築のコードは下記となる。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseSqlite("Data Source=:memory:")
.Options;

var db = new MyDbContext(option);
db.Database.OpenConnection();
db.Database.EnsureCreated();
SQLite の In-Memory データベースでも、インスタンスに名前を付けて使うことができるのだが、上記コードのとおり明示的に名前を付けない場合は、接続を開くごとに異なるインスタンスとなるらしい。

先に書いたように、この振る舞いは単体テストにはうってつけである。

そのこともあり、EntityFramework Core ネイティブの In-Memory データベースプロバイダ使用のときとは違って、"OpenConnection()" 呼び出しにて明示的に接続を開いている。

また、ちゃんと確認できていないのだが、ドキュメントを読み取った感じでは、接続が閉じられる (本件で言うとデータベースコンテキストが破棄 = Dispose される) と、In-Memory データベースインスタンスも即座に破棄されるっぽい。

テスト実行プロセスの期間中ずっと、メモリ上に居座ることはなさそうな様子だ。

トランザクションもつかえる

さすが SQLite というべきか、当然のごとく、In-Memory モードにおいても、データベーストランザクションが機能する。

トランザクションを開始して、ロールバックすれば、データベース状態はトランザクション開始時点のままとなるし、コミットすれば永続化される。

まとめ

EntityFramework Core によるデータベースアクセスを伴うプログラムについて、その単体テスト実装時、揮発性の In-Memory データベースを用いて単体テストを実現する方法としては、以下が挙げられる。
  • EntityFramework Core ネイティブの In-Memory データベースプロバイダ (Microsoft.EntityFrameworkCore.InMemory) を使う
  • SQLite データベースプロバイダ (Microsoft.EntityFrameworkCore.SQLite) を用い SQLite を In-Memory データベースモードで使う

前者は、
  • トランザクションが効かないことと、
  • テスト実行プロセスの期間中、データベースインスタンスは破棄されずにメモリを消費したままとなる心配があるところ
が注意点。

個人的には、SQLite の In-Memory モードを採用の方向で考えている。
 
 

by developer-adjust | 2017-12-22 23:40 | .NET | Comments(0)