バックエンド

開発用モックデータの作成方法で試行錯誤した

MMM Corporation
mmmuser

前田です。
今年の冬は寒いですね。
プチ氷河期に入ったんじゃないかと思っています。

みなさんは、開発する時のモックデータ作成などはどのようにされていますでしょうか?
今回はRailsで、モックデータ作成方法について色々試行錯誤した結果をまとめたいと思います。

方法1: dumpデータを入れる

mysqldumpで吐き出したdumpデータを共有し、各開発環境でDBに入れる、という方法です。
メリットは、実行が早い、migrationをしなくても良い、などです。
弊社ではフロントサイドの方達も、ローカルでAPIを叩く為にRailsの環境を作って、データを入れて、などをしていますが、Railsのmigrationについての知識を習得しなくてもモックデータを準備出来るというのはメリットですね。
デメリットはDBスキーマの変更が発生する時に、dumpデータを毎回準備するのが面倒、というところでしょうか。
開発初期は、DBスキーマの変更が発生しやすいので、その度にdumpデータを新しいものに置き換えて共有する、というのは少し面倒な気がします。
ブランチ毎にスキーマが違ったりなどした時も面倒です。
きちんと対応しようと思ったら、色々なパターンのdumpデータを用意しなければいけない、というのが煩雑なので、開発中(運用前)のスキーマの変更が起きやすい時期のモックデータ作成には向いていないかな、と思います。

方法:2 FactoryGirlを使ってデータを入れる

FactoryGirlはRSpecでモックデータを簡単に作る為のgemです。
どうせテストでFactoryGirlを使って定義していくのだから、そのファイルを使ってデータを作っていったら一石二鳥になるんじゃないかと思ってやってみました。

しかし、開発用のモックデータは出来るだけリアルに近いデータを準備したいので、RSpecのテスト用データを開発用のモックデータとして使用するのは無理がありました。
また、FactoryGirlのデータ作成を、開発用モックデータのような、リアルなデータにする、という方法も試しましたが、そのデータの管理が面倒なのと、RSpecテスト内で開発用データとRSpec用データを作り分けたりすることなどが面倒でした。

方法:3 yaml_db gem を使う

yaml_db gem は、現在のDBに入っているデータをyaml形式のデータにdumpしてくれます。
yaml形式のファイルを直接作成したり、修正したりも可能です。
レポジトリに含めて共有化すると、モックデータ作成の運用が上手くいくのでは無いかと考えていました。

しかし、実際に使ってみると、面倒な部分が多々ありました。

スキーマを変更した時に、すべてのカラムを定義しなければいけない

例えば下記のようなデータがあったとして、

books:
  columns:
  - id
  - title
  - created_at
  - updated_at
  records:
  - - 1
    - ドラゴンボール
    - 2016-02-04 07:00:00.000000000 Z
    - 2016-02-04 07:00:00.000000000 Z
  - - 2
    - スラムダンク
    - 2016-02-04 07:00:00.000000000 Z
    - 2016-02-04 07:00:00.000000000 Z

null: trueのカラムを追加した時でも、各データにこう書かなければいけません。

books:
  columns:
  - id
  - title
  - author
  - created_at
  - updated_at
  records:
  - - 1
    - ドラゴンボール
    -
    - 2016-02-04 07:00:00.000000000 Z
    - 2016-02-04 07:00:00.000000000 Z
  - - 2
    - スラムダンク
    -
    - 2016-02-04 07:00:00.000000000 Z
    - 2016-02-04 07:00:00.000000000 Z

null okのカラムにいちいち追加するのは面倒です。
また、created_atupdated_atカラムもデータを追加した時に一緒に追加しなければいけないのも面倒です。

依存関係を考慮しなければいけない

データを作成する時に、外部キーの依存関係を考慮しながらデータ作成の実行順序を決めなければいけません。
テーブルデータ毎にデータを入れることは出来るのですが、依存関係が複雑になっていくと、このデータを作る前にこのデータを作成して、など、非常に面倒になってきます。
各外部キーに対応したデータをいちいちyamlに書かないといけないのも面倒でした。

また、実行速度も何気に遅いです。
モックデータをファイルで管理出来る、というところは良かったのですが、不満が多かったので、このgemは使いたくないな、と思いました。

原点に戻る

結局どうしたかというと、一番シンプルな方法なのですが、データをrubyスクリプトファイルにして、rails consoleから入れる、という方法が一番良いかな、と思いました。
Railsでアプリケーションを作成している人がモックデータなどを作成する時に、MySQLで入れる人はいないですよね?
たいていはrails consoleからデータを入れている人がほとんどじゃないかな、と思います。

そのコードをそのまま利用するだけで良かったんです。
早く気付くべきでした。

下記のようにrubyスクリプトファイルにし、読み込むだけです。

book1 = Book.create(title: 'ドラゴンボール', author: '鳥山明')
Book2 = Book.create(title: 'スラムダンク')

book1.stores << [Store.create(name: '紀伊國屋書店'), Store.create(name: '蔦屋書店')]
book2.stores << Store.create(name: '三省堂書店')
$ rails runner 'mock.rb'

null okのデータも無視できるし、スキーマ変更に対応しやすいし、依存関係も楽に書けるし、実行速度も早いし、yaml_dbの時の煩雑さは一気に解消されました。
今のところ、上記運用で不満はありません。


RSpecのようなテストだけではなく、目で実際のデータなどを確認するのは非常に大事だと思っておりますので、リアルに近いモックデータを作成することは重要だと考えています。

以上、開発用モックデータの作成方法について試行錯誤した話、でした。

Ruby on Railsを活用したWebサービスや業務システム開発をご検討の企業様は、是非MMMにご相談下さいませ!

AUTHOR
デロイト トーマツ ウェブサービス株式会社(DWS)
デロイト トーマツ ウェブサービス株式会社(DWS)
デロイト トーマツ ウェブサービス株式会社はアマゾン ウェブ サービス(AWS)に 専門性や実績を認定された公式パートナーです。
記事URLをコピーしました