[seasar-dotnet:1232] Re: DBFlute:ReplaceSchemaでの開発方法について

[kubo]

久保(jflute)です。

小林さん、こんばんは

構造的に分析して返答させて頂きますね。

> 案１．S2UnitのExcelデータ取込機能
> 案２．ReplaceSchemaでのテストデータ用意

【案１】
＜メリット＞
1-o-1. テスト間の依存関係がない
1-o-2. テストデータを直さなくてもDB変更ができる

＜デメリット＞
1-x-1. 都度登録なのでテスト実行が遅い
1-x-2. テストデータとDB構造がズレる可能性がある
1-x-3. テーブル定義が大量コピーされDB変更時の修正が大変
1-x-4. DBAがテストデータの管理ができず整合性チェックがしづらい

＜補足＞
「1-x-1」は、デグレ防止のためにコミット前の
全体テスト実行が実質難しくなる。
「1-o-2」は「1-x-2」の裏返しである。
「1-x-4」は「1-x-2」の原因でもある。
エクセルデータの配置工夫次第だが、
マスタデータまで分散させるとマスタ変更一つで
横断的な修正が必要になる。

【案２】
＜メリット＞
2-o-1. テスト実行が速い
2-o-2. テストデータとDB構造がズレない(安全)
2-o-3. DB変更時のテストデータの変更が普通(データ一元管理)
2-o-4. DBAがテストデータに目が届く
2-o-5. UT環境、IT環境、本番環境のデータをそれぞれ管理できる

＜デメリット＞
2-x-1. 他のテストに影響する可能性がある
2-x-2. ある程度ちゃんとした運用を考える必要がある

と、ちょっとこれ以上細かく出すときりがないのでこの辺で。

ReplaceSchemaのデメリットの方ですが、
「2-x-1」はテストのやり方・粒度次第かと思います(Assertの仕方)。
結果件数だけで検証すると確かに影響でますが、内容で検証すれば
問題ないかと思います。
(DBFluteのExampleはそういう風にテストしてることが多いです)
「2-x-2」はいずれにせよちゃんと運用を決めるべきところだと思います。
逆に言うと、それだけちゃんとすれば多くのメリットを享受できるので、
テストデータを管理する役割を明示的に決めた方が良いです。
(DBA的な役割の人を１人増やすだけで何人ものプログラマが楽になります)

ReplaceSchemaの概念が一番反映されているメリットは、
「2-o-2」でしょう。テストデータが修正されないとReplaceSchema
がそもそも正常終了しません。
「DB変更はDDLの変更だけでなくテストデータの修正も含む」
というポリシーで運用することを前提としています。

また、データをただ登録するだけでなく、テストデータの業務的な制約を
チェックする機能もあります。
https://www.seasar.org/svn/sandbox/dbflute/trunk/dbflute-basic-example/dbflute_exampledb/playsql/take-finally.sql
がまさしくそうなのですが、テストデータ登録後に実行します。
結果が期待通りでなければ、ReplaceSchemaが落ちます。
「テストとはいえ不整合なデータでテストするのは許さない」
というポリシーで運用することを前提としています。

上記の分析で、後は価値観次第ではありますが、

> 以前やった（やらかした）失敗としては、
> １．DBを絡めたユニットテストを実装。
> ２．自分の知らない間にDBのテーブル内容が変わった。
> ３．自分の知らない間に通らないテストがいっぱい出来てしまった。
> ４．．．．もうテストする気もしない。もう書かない。（プログラマの反乱）
> の様なことがありました。

という、小林さんの苦い経験を解決するのは、
まさしくReplaceSchemaかと思われます。
無論、DBAがテストケースのプログラムまで直す訳じゃないので、
完全にプログラマが楽になるってわけじゃないですが、
「テストデータ + プログラム」を直すより「プログラム」だけを
直す方がはるかにやりやすいかと思います。

あと、どちらの方法を選んだとしても
「知らない間にDBのテーブル内容が変わった」
ってのは組織的な問題がありますので、
それは「道具」に関わらず直した方が良いかと思います。

また、DBAと言っているのは役割(ロール)であって、必ずしも一人を
想定している訳ではないです。兼任することもあれば二人でやること
もあるでしょう。
(それはどれだけ責務を与えるかでマネジメントでリソース調整します)

さて、このような回答でよろしいでしょうか？？？

2008/12/18 小林貴生 <[E-MAIL ADDRESS DELETED]>:
> いつもお世話になっております。
> 小林（質問者）です。
>
>
> さて、現在悩んでいることがあります。
>
> それは、「DBを絡めたユニットテストの初期データをどうするか。」
> と言うことです。
>
> 以前やった（やらかした）失敗としては、
> １．DBを絡めたユニットテストを実装。
> ２．自分の知らない間にDBのテーブル内容が変わった。
> ３．自分の知らない間に通らないテストがいっぱい出来てしまった。
> ４．．．．もうテストする気もしない。もう書かない。（プログラマの反乱）
> の様なことがありました。
> 上記の経緯があり、その時の自動テストの野望は露と消えてしまったのです。
>
>
> 今度、新しいプロジェクトを始めるので、反省点も踏まえて考えていこうと思っています。
>
> 現在は、
> 案１．S2UnitのExcelデータ取込機能
> 案２．ReplaceSchemaでのテストデータ用意
> のどちらかで、ユニットテスト時の初期データの用意をしたいな。と。
>
> で、今使おうと思っているのは、「S2UnitのExcelデータ取込機能」の方です。
> 理由は、「各テスト毎に初期データがある方が分かりやすいのかな。」と言う
> 簡単な理由なのですが、どうでしょうか？。
> テストソースと同じフォルダにエクセルがあると見やすいのかなぁ、と。
>
>
> うちの開発案件に良くあるのが、テーブルの内容が変わっていくことです。
>
> 例えば、
> １．実績テーブルを作成：初期テストデータとして10レコードデータ作成。
> ２．その10レコードについてのテストＡを書く。通る。
> ３．実績テーブルに何かしら区分カラムが追加（仕様変更）：その区分の有り無しで計20レコードデータ作成。
> ４．その20レコードについてのテストＢを書く。通る。
>
> とやったときに、
> 「S2UnitのExcelデータ取込機能」なら、それぞれにエクセルデータが用意されているので、
> テストＡも、テストＢもエラーにならなくて済むのでは？。
> と考えたのです。
>
> 「ReplaceSchema」だと、20レコードに増やした時点で、
> テストＡが通らなくなってしまうのでは？。．．．と思うのですけど．．．。
> その時で、テストＡを書き直すのでしょうか．．．けど、テスト数が多いとそれも大変そうですよね．．．。
>
>
> もちろん、開発上の工夫をすることによって、上記のような事柄は起こらないように
> されていると思うのですが、よろしければその方法を教えていただけないでしょうか？。
>
>
> DBFluteを使わせてもらい始めた時から、出来れば「ReplaceSchema」でやりたい！。
> と思っています。
>
> 良い方法と言うか、「ReplaceSchema」での当たり前の事でも良いので教えていただければと思います。
> 不躾な質問ですいません、よろしくお願いいたします。
>
>
>
> 以上、よろしくお願いいたします。
>
> 小林貴生
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>