最近のお仕事の話

久々更新になってしまった。。。

仕事が忙しくて死にそうでしたが、一応生きています。つーかオイラの場合、3年くらい前に一度死線を越えてるからこのくらいじゃ死なないぜ(多分。ちょっとだけ強がりかも。。。)。

最近のお仕事は「最近のお仕事の話」で書いたやつの終盤戦です。

うれしい誤算というか、予想に反して(?)みんなちゃんとテストコード書いてますね。おかげでデプロイ後の動作確認とかスムーズに出来てるんじゃないかなぁ。バグはチマチマでているけど、思ったほどじゃないし。テストモジュール書いてよかった。

さて本題。

テストコード書ける環境になったので、最近はずっと TDD で作っているのだけど、時々手が止まることがあります。それがデータモデルが決まっていないときです。「決まっていない」、というか、あいまいだったり、自分で考えなきゃいけないとき、が正確な表現かも。

普通の TDD だと、テストコード書きながらオブジェクトベースなデータモデルが出来ていくのだろうけど、今の環境は DBのテーブルがデータモデルで、ストアドがビジネスロジックだから、テストコードがモデルに直結してこない、っていうのが原因なのかなぁ。テストコードを見ても、テーブルのモデルは必ずしも明確じゃないからねぇ。。。次やるときは O-R マッパーとか試してみて、どうなるかも見てみたいなぁ。

あともう一つ思ったのが、「DBのデータを使うようなテストって、みんなどうやってやってるんだろ？」ってこと。今回の案件はモデルもデータもビジネスロジックも全部DBに入っているから、DBのデータを使ってあれこれしないと何もテストできないんだよね。。。

Java な人達は DBUnit とか使ってるのかな？他の言語にも一応クローンがあるよね。でもさ、XML 書くくらいだったら、コードでテストデータ書くほうが簡単じゃね？。。。って自分は思ったので、気がついたらデータのロードと後始末をする自前の Perl モジュール書いてました。。。データ構造はハッシュね。

ほんと、みんなどうやってやってるんだろ？モデルやロジックはDBから出来るだけ切り離して、どうしてもDBが必要なところはモックオブジェクト使う、とかそんな感じなのかな？

ケント・ベックやマーチン・ファウラーとかが、「流行ってないけどオブジェクトデータベース使ったほうがいいよ」的なことを書籍とかで時々書いてるのはその辺に秘密があるのかなぁ？

オイラのレベルではまだまだ分からん事が多いです。。。やっぱり日々修行ですね。