S2Unit.NET 体験編２ トランザクションの自動制御

更に使い込んでみて思ったのだが。S2Unit.NETの「トランザクションの自動制御」機能ってどういうケースで利用するのだろう。

というのも、テスト対象メソッド(以下、TestTarget)がBusinessLogic層だと仮定した場合、通常RDBMSとのやりとりは外部から見ると隠蔽されているような設計になっている。

S2Unit.NETでこのTestTargetのTestCaseを実装する場合において、S2Unit.NETとTestTargetのRDBMSへのセッションは別物になる。よって以下のようにTestCaseを実装した場合、TestTargetではS2Unit.NETにて投入されたテストデータが参照できない（Commitされていないから）為、テスト自体が破綻してしまう。

＜Test(), S2(Tx.Rollback)＞ _
Public Sub Test
' テストデータ投入
' TestTarget実行
　　↑※S2Unit.NETとは別セッションなのでTestTargetはテストデータが見えない
' 実行結果取得
' Assert
End Sub

と書きながら気づいたのだが。S2Unit.NETの機能を利用する場合、アプリ側もS2Unit.NETを意識した実装を行っておくべきなのだろう。具体的にいうとTestCaseで特化オブジェクトを実装できるようアプリ側を設計する必要があるという事だ。
（アプリ側のDataSourceの生成についてはオーバーライド可能なファクトリーメソッドとして実装すべきで、TestCaseにてこのメソッドをオーバーライドしS2Unit.NETのDataSourceを使える様にしておくべきなのだ。）

まさに先日Mockについて勉強した内容だ・・・。

と、気づいた時には既に遅いのでアドホック対応をしてみた。TestCase内でS2Unit.NETが保持するトランザクションを手動で制御するようにした。
（１）TestCaseのS2属性の引数にTx.NotSupportedを渡す（無しでもよい）
（２）MyBase.Connection.BeginTransaction
（３）テストデータ投入
（４）MyBase.Connection.BeginTransaction.Commit
（５）TestTargetを実行
（６）期待値取得
（７）実行結果取得
（８）MyBase.Connection.BeginTransaction
（９）投入したテストデータの削除
（１０）MyBase.Connection.BeginTransaction.Commit
（１１）Asset