●describeとcontextとit

・解決したいこと

現在実装しているテストは下記のようになっている。
・モデル単体テスト：describeとitでグループ分け
・コントローラー単体テスト：describeとcontextとitでグループ分け
・結合テスト：contextとitでグループ分け

describeとcontextとitを使い分ける考え方について。

・調べた内容、仮説

itでわけたグループがexampleとなる。
テストコード実行後、成功/失敗したテスト数が
「◯example」とターミナルに表示される。

Finished in 4.8 seconds (files took 2.24 seconds to load)
2 examples, 0 failures

このことから、テストの最小単位がitなので、itは必須。

describeとcontextについては、
システム的には必須ではなく、可読性の問題かと推定する。

また、結合テストではit内の記述が長い。
複数のステップをit内で重ねていくが、
それぞれのステップが1つ1つのitとして定義されないのは、
結合テスト＝一連の流れのテストだからだと仮定。

一連の流れというのは、
ユーザーが実際に使う機能を指していて
例えばユーザー登録という１つの機能をテストするならば、

・登録画面に遷移するのも
・登録内容が入力できるのも
・ログイン後の画面にログアウトが表示されるのも

すべて、ユーザー登録という1つの機能を校正する部品。
新規登録するという一連の流れをテストするのだから、
単一部品のテストではなく、
部品があつまって構成される新規登録機能がテスト対象となる。

・質問で深まった理解

describe,contextは、確かに可読性が目的で、あるとより丁寧。
今回の実装の場合は、一部機能の実装なので
グループ分けをする必要がなかったので省略されていた。

itでくくったテストが終わると、一旦リセットされる。
つまり、次のitは新しい状況でテストが始まる。

なので一連の流れの部品をitに分解してしまうと
遷移したデータも、
入力した情報もリセットされてしまう。

＊気づいたこと＊
FactoryBotのcreateアクションが、
ActiveRecordのcreateと動きは同じだが、
・テスト用DBに保存されること
・テスト後データは削除されること
以上2点の違いがあることは知識として脳みそに格納していた。

だが、「そのデータが削除される」ことと
「次のテストは新しい状況でのテストになる」ということを
つなげて考えられていなかった。

いつデータが削除されるのか？
→テストが終わったとき
テストが終わるとは、どのタイミングか
→dexcribeかcontextかitか、
　ここをしっかり考えていなかった。
　
「テストが終わると、データが削除されるんだ。なるほど、理解した。」
と、わかったつもりになり、
それ以上考えることを遮断していた。

知識があったから、
保存していた知識を呼び出してきて
今回の話がつながったわけだが、

そもそも知識が入った際に
知識の置物として保存しておくだけ、というのは
イケてる勉強方法ではないよなぁ、と感じた。