[wip] specを書く

このPRで何をするか
---------------------------------------
テストを書きます。

終了条件（どうしたらWIPが取れるか）
------------------------------------------
前回までの機能をテストするfeature specを書くこと
（まだ検討中です）

前回PRとの関係
------------------------------------------
前回まではspecを書いていませんでした。テストが必要だとのご指導があり、また自分もその必要性を感じたため今回のPRで書くことにしました。



テストと言っても色々あるので、前回僕が言いたかったことの補足っぽいことを書いてみます。
(TDDとかコミットしないテストの話とかは抜きで)

### なぜテストを書くか

自動テストを作成する理由は、動作確認を自動化するためというのが大きいと思ってます。

コードを書くときは必ず何かしらの想定している振る舞いがあるはずだけど、
それをただのドキュメントで書くよりは実行できるテストにすることで次のようなメリットがあります。

* テストを実行するだけで、同じ動作確認を誰でも行うことができる
* 動作確認の時間を短縮できる

手動で動作確認する場合、誰でも同じ動作確認をできるようにするのは結構大変です。
実行環境や用意するデータの内容、確認手順、確認項目を全てドキュメントにした上で、
動作確認する人が誤り無く実行する必要があります。
自動テストならば、実行時の誤りは心配する必要はなくなります。
(RSpec等のライブラリのバグを踏むケースはありそうだけど)

動作確認の時間を短縮できるは非常にありがたくて、ほんの小さな変更を行った場合でも
自動テストで担保できている範囲の動作確認は気軽に行うことが出来ます。

ただし、全ての動作確認を自動化することは出来ないので、手動の動作確認も当然必要です。
手動の動作確認中にバグが見つかることも多々あるので、僕は手動の動作確認も自動テストと同じくらい大切だと思ってます。

### テストをいつ書くのか

理想的には常に書けばいいと思います。
しかし過剰にテストがあると次のような弊害が出てくると思います。

* テストを書くのに時間がかかる
* テストの実行スピードが遅くなる
* テストコードが読みにくくなる

そのため、無駄なテストやメリットの少ないテストは少なくします。

#### 無駄なテストとは

他のテストで担保できていることを確認しようとするテストは無駄だと思います。

例えば、モデルのテストでバリデーションエラーのテストがあるにも関わらず、
Featrue のテストでバリデーションエラーをチェックすることは無駄です。
(そもそも大変だし)

ただし、 Featrue のテストでバリデーションエラーをチェックしていたとしても、
エラーメッセージがどのような位置に出ているか等エラー発生時の画面の振る舞いを
確認するテストであれば無駄ではないと思います。

#### メリットの少ないテストとは

テストを書くこと、増やすことによる弊害と比べてメリットが少ないテストのことです。

今回の `#order_details` は実装の単純さを考えると、想定していることはコードを読むだけでわかるし、
何か不具合が発生しそうな不安もありません。

そのため僕がコードを書くなら、 `#order_details` のテストは書かないか、
書いてもコミットせずに捨ててしまうと思います。

ただ、 @onionSoup に関しては書いてもいいと思います。
理由は、次の通りです。

* 単純にテストを書く練習
* まだテストの総数が少ないので実行時間を気にする必要なし
* Rails や Ruby の動作について僕よりは不安が大きいはず