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