【結論】
・統合テスト→単体テストの順に書くと良い
・統合テストでカバーしきれなかった部分を
単体テストで記述する事で、
バグの検出を確かなものにする
【目次】
【本題】
テストコードを書く順番
テストコードには大きく分けて、
単体テストと統合テストが存在します。
単体テストとは、コントローラーのメソッド単位など
一機能毎に正常動作するかチェックできるテストです。
統合テストとは、編集ボタンを押してフォームに入力し送信ボタンを押すといった
実際にユーザーが行う一連の操作が正常に実行できるかチェックするテストです。
これらは、どちらか片方が欠けてしまうと、
バグを見逃してしまう可能性があるので、
両方とも実装するのが望ましいです。
（実際は、開発スケジュールにもよる）
では、どちらから実装すれば良いのでしょうか？
統合テストから書いた方が良い
結論にも書いた通り、統合テストから書く方が望ましいです。
何故なら、統合テストで、一通りの動作のチェックが網羅できるので、
後は、統合テストでカバーしきれない部分を、
単体テストで補おう様に実装した方が、効果的だからです。
かの有名なRSpecの著書である
「Everyday Rails - RSpecによるRailsテスト入門」にもこの様に記述されています。
フィーチャスペックをパスさせるために開発していると、他のレベルでテストした方が良い機能が見つかります。たとえば、前章ではモデルレベルでバリデーションをテストし、コントローラレベルで認証機能をテストしました。よくできたフィーチャスペックはそのフィーチャが関連するテストのアウトラインを導き出してくれます。
Aaron SumnerとJunichi Ito (伊藤淳一)とAKIMOTO Toshiharu and 魚振江. Everyday Rails - RSpecによるRailsテスト入門 (Kindle Locations 6569-6572).
様々な技術書やカリキュラムは、単体テスト→統合テストの順に
テストコードの記述方法を教えているケースが多いですが、
慣れてきたら、統合テストから書いた方が良いでしょうね。
参考情報
Everyday Rails… Aaron Sumner 著 et al. [Leanpub PDF/iPad/Kindle]
《今日の学習進捗（3年以内に10000時間に向けて）》
個人開発のタスク管理が非常におざなりになってきている・・・
個人アプリでは遅延しても誰の迷惑を掛ける事は無いので、気が緩んでしまう・・・
Twitterで教えて貰ったGoogleカレンダーに細かくタスク埋め込んで
管理するやり方とかを参考に、きっちりとコントロールして行きたい。
そして、これ書いた後にQiita書くの大変過ぎる・・・もう二度とやらん！！
学習開始からの期間 ：146日
今日までの合計時間：1419h
一日あたりの平均学習時間：9.8h
今日までに到達すべき目標時間：1333h
目標との解離：86h
「10,000時間」まで、
残り・・・「8581時間！」