[seasar-dotnet:1567] Re: QuillTestCase でReadXlsWriteDbすると

[kubo]

久保(jflute)です。

> dfnet-basic-exampleを動かしてみて、何が違うか調べてみます。
> #目検すると違うようには見えないので、動かしてみます。
ぜひ、よろしくお願いします。
QuillTestCaseの不具合なら修正して
新しいバージョンに反映させられると思います。

> 百を超えるテーブルがあり、開発チームもたくさんあり、拠点も複数といった
> 状態での開発ですと、マスタ系のテーブルならともかくトランザクション系のテーブルは
> ReplaceSchemaでデータ管理するのが大変だなっと思い、
> いろいろな術を調査しておりました。
> おっしゃるように、
> チーム毎にReplaceSchemaでデータを管理してもよいようにも思えてきました。
> この辺りは、今回の状況での最善方法を、引き続き探っていこうと思います。
規模が大きければ大きいほどReplaceSchemaの効果も大きいので、
少なくともマスタ系のデータだけでもReplaceSchemaで
登録できればトラブルが減るかと思います。
(個人的にも百・二百を超えるテーブルの
システムでReplaceSchema使っておりました)

トランザクション系のデータは確かに難しく、
単純に考えると、テストデータ作成・管理コストを：

A. 複数チームを束ねるチームで一元管理
B. 開発チームに委ねる
C. 個々のプログラマに委ねる

と、どこに配置するかに尽きます。
大規模ならなおさら "C" は(個人的には)あまり
お奨めしません。体制が組めれば "A" が理想ですが、
確かに経験したことがないといきなりは腰が重いかもしれません。
"B" はおっしゃる通り現実的な感じかもしれません。

また、トランザクション系データの全てのテストケース
を準備するのではなく、ある程度典型的なケースのものだけ
統括チームで作成して、プログラマがそのデータを
"テストプログラムの中でちょっとだけupdateして"
自分のテストに都合の良いデータにする、というのも
現実的だと思います。というか結構こういうパターンで
実際にやってるところもあります。
(全テストケースの作成はなかなか難しいので)
AとBとCとのマージのような感じになりますね。
とにかくエクセルデータが管理できない領域に
バラけるのだけは防いだ方が良いという感じです。

参考までにという感じで。
あと、技術的な話だけでなく、こういう利用方法の
ポリシーの相談とかもMLで遠慮なくして頂いて
構いませんからね。

#
# あと、そもそもReplaceSchemaのドキュメントが
# 公式サイトにないのがよくないですね...本当すいません。
# あと一ヶ月後くらいには完全なドキュメント出せるか
# と思いますので。(こういった話も含めて書こうかと)
#

2010/3/8 ikutirin <[E-MAIL ADDRESS DELETED]>:
> 久保様
> 返信ありがとうございます。
>
>> > ReadXlsWriteDb()を呼び出しているタイミングは、
>> > テストケースのメソッドの中でしょうか？
>> > ([MbUnit.Framework.SetUp]の中とかではなく)
> [MbUnit.Framework.SetUp]とテストケースのメソッドの中、
> 両方試してみましたが、同じ結果でした。
>
>> > また、dfnet-basic-exampleのApp.configと比べて、
>> > 何か違いがあったりしないでしょうか？
> assemblysを記述する位置が違ったので、dfnet-basic-exampleと同じようにしましたが、
> 結果は変わらず。
>
> dfnet-basic-exampleを動かしてみて、何が違うか調べてみます。
> #目検すると違うようには見えないので、動かしてみます。
>
> また、
> 百を超えるテーブルがあり、開発チームもたくさんあり、拠点も複数といった
> 状態での開発ですと、マスタ系のテーブルならともかくトランザクション系のテーブルは
> ReplaceSchemaでデータ管理するのが大変だなっと思い、
> いろいろな術を調査しておりました。
> おっしゃるように、
> チーム毎にReplaceSchemaでデータを管理してもよいようにも思えてきました。
> この辺りは、今回の状況での最善方法を、引き続き探っていこうと思います。
>
> ありがとうございました。
>
>
> kubo <[E-MAIL ADDRESS DELETED]> wrote:
>
>> 久保(jflute)です。
>>
>> Unitテスト時、Excelに初期データを用意して、結果をExcelで比較して
>> 発生した現象の原因を掴むのが大事なことには変わりはありませんが、
>> アドバイスとして一つ。
>>
> DBFluteとしては、テスト実行時にテストケースごとに
>> テストデータを用意して登録してテストするのではなく、
>> DB環境構築時にある程度のケースを網羅したテストデータを
>> あらかじめ登録しておいてテストをするやリ方を
>> お奨めしています。具体的にはReplaceSchemaタスクを
>> 利用して、事前にテストデータを登録しておきます。
>>
> こちらの記事参考になります。
>> http://d.hatena.ne.jp/jflute/20100222/1266826083
>>
> テストケースごとにExcelを用意すると、
>> テストケースが増えて来たときに全体のテスト実行が
>> とても時間が掛かってしまうのと、いくら(DBFluteで)
>> プログラムはDB変更に強くても、テストデータがDB変更に
>> 弱いということになってしまうからです。
>>
> 無論、既にReadXlsWriteDbを利用することが決まってるなら、
>> 無理に移行することはないですが、参考までにということで。
>>
> #
>> # 個人的には、ReadXlsWriteDb()を使ったことなくって、
>> # 周りのDBFluteプロジェクトでも、使ってる人を
>> # ほとんど聞いたことないという感じです。
>> #
>>
> 2010/3/5 kubo <[E-MAIL ADDRESS DELETED]>:
>> > 久保(jflute)です。
>> >
>> > こんばんは
>> >
>> > こちらでdfnet-basic-exampleで試してみましたが再現しませんでした。
>> > WinXP / Quill-1.3.17.0 / DBFlute-0.8.9.12-RC2 / MbUnit 2.3
>> >
>> > テストケースのメソッドの中で
>> > IDataSource s = this.DataSource;
>> > とやっても、該当のエラーは発生しませんでした。
>> > this.DataSourceでしっかりDataSourceが取得できました。
>> > ToString()：SelectableDataSourceProxyWithDictionary
>> >
>> > ReadXlsWriteDb()を呼び出しているタイミングは、
>> > テストケースのメソッドの中でしょうか？
>> > ([MbUnit.Framework.SetUp]の中とかではなく)
>> >
>> > また、dfnet-basic-exampleのApp.configと比べて、
>> > 何か違いがあったりしないでしょうか？
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>