テストプロセスに関して

日々是テスト。

プログラマになってから数年がたちますが難点はずっと同じでテストですね(汗)

以前にかいたエントリーなどは下記参照。

参考
データベースによるテストデータ作成
 Excelによるテストデータづくり
 テストについて

特にデータベース(特に更新系)が入るパターンです。

かなり悩んでおり、きれいな正解はないんですが、個人的に思っていることを。

基本的には以下の流れは変わらないと思います。

前提となるデータの用意
実際の処理
結果の照合
データの削除

一般のフレームワークだと上記の流れを自動化させていますね・・Cakeに限って言うと前提データと結果のデータをハードコーディングしないといけないのがキツイです。大量のデータでは厳しいですね・・・・

Contents

1 前提となるデータの用意
2 実際の処理
3 結果の照合
4 データの削除
5 その他の心構えなど

前提となるデータの用意

要は目的の処理をやる前に必要となるデータのこと。これを用意しておかないといけません。一般的にはデータベースやテーブルをすべて初期化してからデータをいれることが多いですね。

テストフレームワークはそういう構成になっているものが多いです。ない場合でも自力でそれを作らないとデータ作るまでが異常に大変だったり、一意制に引っかかってしまってデータをいちいち変えないといけないなどさまざまな手間が発生します。

思いついた＆実行したやり方は以下の方法

テストデータを直接ハードコーディング

一般的なテストフレームワークではプログラムの中に書きます。

CSVでは用意が厳しいもの、データ量が少ないものはこの方法が良いっぽいです。ただし大量データだったり、列数が多いと作るのがすごい大変だったりします。

基本的には上記の中のどれかを取捨選択(あるいは折衷案)で使っています

mysqldump

mysqldumpで前提データを用意しておいてそのまま入れます。原始的ですね・・もっとも確実にデータを容易できるメリットはありますが、細かい処理でやることではない気がします。dumpをとって時間がたつとデータの状態がどうなっていたかを覚えておくのもほとんど無理で、保守性はありません。データ入れるのに少し時間がかかるのも難点です。大型の処理用やidなど本当に完全に同一なデータを用意したいとき。やる場合に備えてデータベースサイズを極力絞りましょう。

INSERT文

単純なパターンならこれでいいと思います。ただINSERTでデータを入れるとデータとして正常でなく、不整合を起こす場合などもあります。複雑なデータはある個所にデータが入ると別の個所にもデータ更新をされることが一般的なので複雑なデータタイプには向かないと思います。

ストアドプロシージャ

やったことないんですが、使えるかも・・・プログラム的なことが書ける分、大量のSQLにはいいのではないかと思います。ただINSERT文のデメリットを克服できてはいないかと思います。

データを入れるプログラムを書く

複雑なデータを用意する場合、INSERTではなく、プログラムを通したほうが関連するテーブルを更新でき、正常なデータに近づけることができます。要はデータを入れるバッチを書くことになります。ただWEBでやっている処理をバッチで書く場合、限界もありますね。めんどくても作っておくとあとあとすっごい楽です。。

実際の処理

高速でできることが必要なので極力ブラウザをポチポチやるのではなく、バッチで一気にいけるのが理想です。ただ現実は厳しい場合もあります。一部分だけバッチでやり、なるべく負担が少ない量をWEBでやるのがいいでしょう。

小さいメソッド単位はいいですが複雑な処理全てをバッチだけで行うのは(もともとそのように意識していない限りは)かなり難しいかと思います。

ただしなるべくその状態に近づけることは大事で、普段のプログラムを書く際にも下記のようなことを心がけましょう。

なるべく関数同士を独立させる
クリエストパラメーターやセッション変数、データベースにかかわる処理をなるべく関数の中に書かない
なるべく短くし、テストをイメージしてからメソッドを書く

結果の照合

小さい単位であれば、一般的なユニットテストのように結果をハードコーディングしておき、状態がだたしいかどうかを書いておけばいいんでしょうけど(いわゆるassertTrueみたいなかんじでのチェック)大量かつ複雑な処理だと難しいと思います。

私がやったのはSQLを書いてCSVで吐き出し、期待値を用意しておいて差分をとるのがいいと思います。プログラムで書いておけば(シェルスクリプトがカンタンでお勧めです。)すぐにCSVだせますし、差分をとれば一瞬でわかります。今日やりましたがかなり使える方法でした・・今までやればよかった。備考みたいな項目にテストデータの意味を書いておくと試したときにすぐにチェックできて楽です。

データの削除

大体のシステムは重複を禁止しているデータがあることが多いため、一度データをいれると、次から前提データが使えません。そのため、関連するデータは削除しておいたほうがいいと思います。消さないとやったことをわすれて後で同じデータを入れたときに動かないで焦る・・・・ということになりがちです。始まる前にも当然削除はしましょう。

どれが関連しているデータかを判定するのが何気に難しいですが、作成時間＆データ作成者=自分みたいなプログラムを書いておいて実行するのが良いでしょう。

この処理はストアドプロシージャでやらせてもいいと思います。

その他の心構えなど

ポイントとしては1～4がどうやったら高速のサイクルでできるかを考えること、なおかつデータを保存する意識がないとダメですね。データが風化してしまうと使えなくなります。ここら辺は仕様書の管理などと同じかもしれません。

ただし、システムの変化が激しい場合は保存しても数か月後に見返すと意味のないデータになっていることもあります。その場合、データ自体よりはやはりデータの作り方をメモしておいたほうがいいかもしれません。あるいは普段からシステマチックなテストケースの作り方を心得ておく。複雑なデータケースだとやはり見やすいのでExcelがあると便利ですね。