Skip to content

Latest commit

 

History

History
95 lines (68 loc) · 6.12 KB

File metadata and controls

95 lines (68 loc) · 6.12 KB

MakingTestData

テストデータ作成における課題

  • 仕様的に整合性のある正しい(生きた)データを作るのがそもそも大変
  • 上記の条件を満たしており、テストを網羅できる大量のデータを作るのがそもそも大変
  • このタスクの重要度自体がなおざりで、ケース作成なかで工数として見積もられていない

全般の対策

  • 仕様的に整合性のある正しい(生きた)データを作るのがそもそも大変
  • 上記の条件を満たしており、テストを網羅できる大量のデータを作るのがそもそも大変

共通で必要になる対策

  • 仕様がわかる人材、お客さん、あるいは近いフェーズの人のアドバイスによるデータ作成

個別対策その1プログラム(API)や各種バッチ、登録処理のService層 をそのまま使う

登録系の処理を利用して、登録部分のモジュールを走らせ、テストデータを大量に入れる手法です。(一番確実で綺麗なデータが作れます)

メリット

  • 仕様的にデータの整合が取れる
  • 乱数、日付の範囲選択などカスタマイズされたお手軽なデータも自在に作れる
  • 大量データも自在に作成可能

デメリット

  • この条件を揃えることが難しい
    • プログラムで回せるように登録処理が書かれていることが前提になる(登録部分が独立して切り出されていてモジュール化が可能)
    • 開発途中で使えないなどの制限がない
    • そもそも登録処理自体が他のベンダー開発担当でさわれない・・・など制約がないか
  • エンジニアでないとNG
  • 仕様をある程度理解していないとどのAPI、バッチが使えるのかがわからない

個別対策 その2 シーディング(Seeding)

主にケースごとにデータ投入用のプログラムを用意しておき、そこから入れる方法です。

ちなみに「テスト Seeder」で検索するとほとんどLaravelがでてきますね・・・

メリット

  • プログラムを最大限、活用できる(繰り返しや条件分岐はもとより、継承や抽象化など)
  • Modelからデータを作成するため、DB制約に気づけ、テーブルの整合性にある程度気付ける(外部キーで落ちるなどに気付ける)
  • 仕様が完全にわかっていなくても使える(ある程度部分的な理解でもOK)
  • 大量のデータなども自由自在(後述するExcelのような制限がない)
  • 典型的なものはダミーデータもある程度作成が可能

デメリット

  • 名前空間が分かれている場合、本体側のプログラムを使うことに制限がでてくることもある
  • エンジニアでないとNG
  • 仕様をそれほど理解していなくてできる反面、あり得ないデータができてしまう(仕様間の整合は完全に保たれない)
  • Modelのディフォルト値や可変な値を自由に切り替えられる仕組み(Laravelでいうfactory()->create())がないと面倒 (Frameworkを使っているなどの前提条件がある程度必要)

個別対策その3 Excel→SQL

レガシーな環境で一般的によく使われてる方法だと思いますが、ExcelでデータをSQLなどで機械的に作る方法です。

メリット

  • 準備や環境にやさしい(ExcelがあればOKなのでほぼ環境に依存しない。レガシーな環境やテストに対する知見がそれほどなくても大丈夫)
  • 単純な乱数やマスタ参照なども作成が用意
  • マクロ、標準対策の関数を組むことで、ちょっとしたカスタマイズが可能
  • 大量データを作るのがある程度可能(万をこえるものはやめた方がよいかも)
  • 簡単なGUIの画面などをつくることも不可能ではない
  • 簡単なため非エンジニアでもいじれる

デメリット

  • SQLを直でいれることになり、Modelから生成するわけではないので、テーブルへのデータ挿入の担保がされない
  • ↑と同じだがプログラムの変更との差分ができてしまう
  • 生きたデータを作るのが難しい
    (アドバイザーがいないと仕様的に正しくても実ケースに即したデータ作りにくい。seederと同様のエラー)
  • ものすごい大量のデータを作ろうとするとファイルが重くなる
    (1テーブル1万程度が目安)
  • 関連テーブルが多くなると整合を取るのが難しい(Seederのようにプログラムを触らないので把握が困難で、検証に若干手間がかからる)
  • seedingほど自由が効かない

個別対策その4 ノーコード &ローコードアプリ

やったことないんですけどモック&模擬テストデータとして、ノーコードやローコードなどで簡単な画面とデータの関連を作る方法です。(やや妄想です。)

ローコード自体はkintoneってアプリで過去やったことあるんですが、その時の記憶を頼りにメリデメを挙げております。

メリット

  • 低コスト(インフラ、プログラミング環境構築不要)で、画面+簡単なデータ環境を作ることが用意
  • 関連テーブル数が多くなっても仕様的に正しいデータを作ることができる
  • モックレベルのものが簡単にできる
  • 環境をweb上に公開するので共有が楽(お客さんに共有しやすい)
  • ちょっとしたプログラムを組めることもある(kintoneの場合はJavaScript)

デメリット

  • モックを作る手間を許容してもらう必要がある(あるいはそもそもそういった前提が必要)
  • ある程度の学習コストが必要(学習コストはExcel以上、プログラミング言語での環境構築以下という感じ)
  • カスタマイズに限界がある(カスタマイズ性はExcel以上、プログラミング言語での環境構築以下という感じ)
  • 画面から入力することになるので、大量のデータを作ることがそんなに簡単ではない