skillup

技術ブログ

ドキュメント作成 プログラミング全般

テスト環境のデータ作りに関して

投稿日:2021年12月11日 更新日:

単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。

以前もこのネタに関しては色々書いてますね。

ダミーデータの作り方 まとめ

テストデータを作るのが大変・・・といっても色々あると思いますが、以下のような点ですかね。

問題点

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

対策全般

共通で必要になる対策

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

個別対策その1プログラムをそのまま使う

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

メリット

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

デメリット

  • この条件を揃えることが難しい
    (プログラムで回せるように登録処理が書かれていることが前提になる、そもそも登録処理自体が他のベンダー開発担当でさわれない・・・など制約がないか)
  • 仕様をある程度理解していないと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以上、プログラミング言語での環境構築以下という感じ)
  • 画面から入力することになるので、大量のデータを作ることがそんなに簡単ではない

現実のプロジェクトではその2をベースに部分的にその1、3を活用するのがいいのでは・・・・と思っております。モックまで作らせてくれるケースはあまりないですかね?

なお、以前あげたwebサービス(人名とか)活用とかは利用できる範囲が狭いのでちょっと難しいですね・・・

記事書いたらkintoneやりたくなってきました・・・(汗)

-ドキュメント作成, プログラミング全般
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

業務管理アプリの商品コードに関して

一般的な業務管理アプリを作っていると商品や顧客などもオートインクリメントのidではなく、独自の仕様で決められた「商品コード」などを持っていることが一般的です。 昔通販がらみのシステムを使っている時も商 …

no image

便利すぎる道具の弊害

現在、Javaのプロジェクトでは会社でNetbeansを使っていますが、IDEを使っているばっかりに理解できていないところがありました。便利すぎる道具の弊害ですね・・・ IDEについて一応説明をしてお …

no image

PHPの例外クラスについて

PHPの例外クラスについて今まで一方的にExceptionで受けており、それ自体は問題なさそうですが、 一応再度確認。 Contents1 エラークラスの分類2 Throwableに関して3 Exce …

no image

ドメイン決定&業務フローとの対応確認

Contents1 ドメイン決定2 業務フローとの対応2.1 実際の業務とエンティティ、画面の遷移2.2 ドメインのCRUD分析 ドメイン決定 業務フローを抽出し、エンティティを抽出した段階で次にドメ …

no image

ファジープロジェクト対策 その2

前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 Contents1 テンプレート共通化2 バリデーション3 ログ出し4 異常系の処理5 新規プラグイン+ …

アーカイブ