新人SEに向けて~はじめてのrspec編~④
現場に入ってRSpecをいじることになったけど、何をすればいいかよくわからない、そんな人に向けた記事。
※この記事ではRSpecをspecと略します。現場の人も大体スペックって呼ぶし。
前回の続き。
今回は「実際にテストデータを用意するときの考え方」 を扱う。
どっちかというとFactoryGirl、FactoryBotに関する話になる。
想定する状況
前回の例を引き継ぐ。
一般ユーザと管理ユーザが存在するプログラムにおいて、「準管理ユーザ」を新設する想定で話を進める。
それぞれのユーザはアプリ上でファイルを操作するものとする。一般ユーザは自分の所有するファイルのみ編集可能だが、管理ユーザは全てのファイルを扱える。
新設する「準管理ユーザ」は、一般ユーザの一部を管理できる特殊なユーザである。しかし管理の対象になっていないユーザのファイルは編集できないものとする。
モデルの関連性を見る
Railsでは、DBに格納するデータの型をモデル(Model)として定義する。
※DBに格納しない場合でもモデルを作成することはあり得る。詳しくは知らないが
今回は、「一般ユーザ」「管理ユーザ」「ファイル」をそれぞれモデルにしていると仮定しよう。モデルの関連性は以下のようになる。
次、準管理ユーザを組み込んだ場合。
今まで殆ど文章で説明してきたが、ここで図がちょっとキモチワルイことになっていることに気付くだろうか。
「管理ユーザ」から「準管理ユーザ」に行く場合もあれば、「一般ユーザ」に伸びる場合もあるのだ。スッキリしないが、今回はこのまま話を進めていく。
モデルの関連性を見る理由
結論から言うと、DBのテーブルにおいて、どのようなカラムが必要なのかを明確にするためである。
以下はDB寄りの話になるが、お付き合いいただきたい。
DBにはテーブル単位でデータが格納されている。
開発者たる我々には、上図のような形でテーブル同士が関連しているように見えるが、DB内部ではモデルの名前を冠したテーブルが別個に存在するだけだ。
先ずold の方から見ていこう。
old構成のカラム
一般ユーザは、複数のファイルを所有している。このとき、「ファイル」テーブルに「user_id」カラムがあれば、そのファイルがどんな一般ユーザに属しているのかがわかるだろう。
加えて、一般ユーザは管理ユーザと紐づいているので、「一般ユーザ」テーブルに「admin_user_id」があれば、一般ユーザと管理ユーザの関係性も明確だ。
new構成のカラム は明日までの宿題!
今回は敢えてここで記事を切ってみる。new 版の構成だとどんなカラムが必要になるか、是非考えてみてほしい。
おわり
終わリスペクト!(特に意味はない)
今回はここまで。
次回は、今回の答え合わせをしていきます。new 構成のカラムは、old構成のカラムとどう違うのか。
また次回予告とズレた・・・もう開き直ったわ、解説にあたって必要な知識って、意外と沢山あるってことで!(投げやり)
コメントで感想や指摘いただけると助かります!
それでは!(`・ω・´)