[output]モデル単体テスト

モデル単体テストは、バリデーション及びメソッドの検証。

異常系テストにおいては、
presence: trueというバリデーションがあるなら、
カラムを空にして、エラーメッセージを検証する、と
バリデーションを参考にイグザンプルを組み立てやすい。

対し、正常系テストは、
アプリの仕様・動作の流れも参考にして、組み立てる必要がある。
例えばユーザー登録というdescribeならば、
「○○と△△と□□のデータがあれば、登録できる」というイグザンプルの検証が必要になる。

バリデーションについて、
自らが設定したバリデージョンは、モデルファイルで確認できる。

それに加えてdeviseが自動で設定するバリデーションも検証対象である。

例えば
e-mail：存在すること、一意であること、＠を含むこと
password：存在すること、6~128文字であること

など。

これらの一部は、config/initializers/devise.rbで確認できる。

#記述抜粋
config.password_length = 6..128
config.case_insensitive_keys = [:email]
config.strip_whitespace_keys = [:email]
config.email_regexp = /\A[^@\s]+@[^@\s]+\z/

次に正常系テストについて。
マチャはbe_valid?がよく使用される。

これはexpectの引数に対して、裏でvalid?を実行しtrueかどうか確かめるマッチャである。
そのため、このマッチャ自体に引数は不要。

expect(@model).to be_valid

ここまでくると、
正常・異常系のテストコードがdescribe内に混在するわけだが、
dexcribe：何についてのテストか

it：どんな状況でテストを行うか　に加えて、

正常系テスト、異常系テストなど更に特定の条件を記述するのにcontextが使用できる。

また、FactoryBotでインスタンスを作成しテストを行なっているが
テストモデルがbelongs_toのアソシエーションをもつ場合、

belongs_toの自動バリデージョンが起動し、
関連モデルのidカラム及びレコードが存在するかがチェックされる。

つまり、関連モデルのインスタンスも存在しないと
valid?でfalseが返ってきてしまう。

それを解消するために、
FactoryBotでもアソシエーションを記述する。

記述するコードは「association」で、これを記述したモデルが生成されると
自動で関連モデルも生成してくれる。

先のbelongs_toのもっているバリデーションに対応するためなので、
紐づくモデルが必ずしも存在しないモデルには記述不要となる。

このアソシエーションの検証をする際、関連モデルを空にする必要があるが、
これにはnilを代入することで、行える。

補足すると、
""(空文字)は、文字列なので、インスタンスに代入するには型が違い不適当。
destoryは保存されたインスタンスに対する削除のため、
buildを使用する今は使用不可。