単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。
以前もこのネタに関しては色々書いてますね。
テストデータを作るのが大変・・・といっても色々あると思いますが、以下のような点ですかね。
Contents
問題点
- 仕様的に整合性のある正しい(生きた)データを作るのがそもそも大変
- 上記の条件を満たしており、テストを網羅できる大量のデータを作るのがそもそも大変
対策全般
共通で必要になる対策
仕様がわかる人材、お客さん、あるいは近いフェーズの人のアドバイスによるデータ作成
個別対策その１プログラムをそのまま使う
登録系の処理を利用して、登録部分のモジュールを走らせ、テストデータを大量に入れる
メリット
- 仕様的にデータの整合が取れる
- 乱数、日付の範囲選択などカスタマイズされたお手軽なデータも自在に作れる
- 大量データも自在に作成可能
デメリット
- この条件を揃えることが難しい
(プログラムで回せるように登録処理が書かれていることが前提になる、そもそも登録処理自体が他のベンダー開発担当でさわれない・・・など)
個別対策その2 Excel &プログラム
一般的によく使われてる方法だと思いますが、Excelで機械的に作る方法です。
メリット
- 単純な乱数やマスタ参照なども作成が用意
- ExcelがあればOKなのでほぼ環境に依存しない
- マクロ、標準対策の関数を組むことで、ちょっとしたカスタマイズが可能
- 大量データを作るのがある程度可能
- 簡単なGUIの画面などをつくることも不可能ではない
デメリット
- 生きたデータを作るのが難しい
(アドバイザーがいないと仕様的に正しくても実ケースに即したデータ作りにくい) - ものすごい大量のデータを作ろうとするとファイルが重くなる
(1テーブル1万程度が目安) - 関連テーブルが多くなると整合を取るのが難しい
- GUIなど凝ったものを作ることは難しい
個別対策その3 ノーコード &ローコードアプリ
やったことないんですけどモック &模擬テストデータとして、ノーコードやローコードなどで簡単な画面とデータの関連を作る方法です。(やや妄想です。)
ローコード自体はkintoneってアプリで過去やったことあるんですが、その時の記憶を頼りにメリデメを挙げております。
メリット
- 低コスト(インフラ、プログラミング環境構築不要)で、画面＋簡単なデータ環境を作ることが用意
- 関連テーブル数が多くなっても仕様的に正しいデータを作ることができる
- モックレベルのものが簡単にできる
- 環境をweb上に公開するので共有が楽(お客さんに共有しやすい)
- ちょっとしたプログラムを組めることもある(kintoneの場合はJavaScript)
デメリット
- ある程度の学習コストが必要(学習コストはExcel以上、プログラミング言語での環境構築以下という感じ)
- カスタマイズに限界がある(カスタマイズ性はExcel以上、プログラミング言語での環境構築以下という感じ)
- 画面から入力することになるので、大量のデータを作ることがそんなに簡単ではない
現実のプロジェクトではその２をベースに部分的にその３、その1を活用するのがいいのでは・・・・と思っております。
なお、以前あげたwebサービス(人名とか)活用とかは利用できる範囲が狭いのでちょっと難しいですね・・・
記事書いたらkintoneやりたくなってきました・・・(汗)
