テストコード、単体テストから書くか?統合テストから書くか?

f:id:ryoutaku_jo:20190502220306p:plain

【結論】

・統合テスト→単体テストの順に書くと良い

・統合テストでカバーしきれなかった部分を
 単体テストで記述する事で、
 バグの検出を確かなものにする

【目次】

【本題】

テストコードを書く順番

テストコードには大きく分けて、
単体テストと統合テストが存在します。

単体テストとは、コントローラーのメソッド単位など
一機能毎に正常動作するかチェックできるテストです。

統合テストとは、編集ボタンを押してフォームに入力し送信ボタンを押すといった
実際にユーザーが行う一連の操作が正常に実行できるかチェックするテストです。

これらは、どちらか片方が欠けてしまうと、
バグを見逃してしまう可能性があるので、
両方とも実装するのが望ましいです。
(実際は、開発スケジュールにもよる)

では、どちらから実装すれば良いのでしょうか?

統合テストから書いた方が良い

結論にも書いた通り、統合テストから書く方が望ましいです。

何故なら、統合テストで、一通りの動作のチェックが網羅できるので、
後は、統合テストでカバーしきれない部分を、
単体テストで補おう様に実装した方が、効果的だからです。

かの有名な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時間!」