※ 本講座は、動画コンテンツが未作成です。
Contents
はじめに
rspec でのテスト実装に入る前に、そもそもなんでテストなんて書くのが面倒なものを書かなきゃいけないのかについて理解しておきましょう。
Rails で動くアプリを作るだけなら、テストなんて面倒なもの本来やらなくてもいいんですよね。
テストを書いたところで
- 新しい機能が増えるわけではない
- 見た目が綺麗になるわけではない
- プログラムが速くなるわけではない
そのくせ、テスト実装という手間が増える。いいことなさそうですよね。
でも、それでも Rails で仕事をするなら、絶対に身につけて欲しいのが rspec でのテスト実装です。
具体的なスキルを身につける前に、しっかりとそれを身につける意義を知っておきましょう。
テストがないと起こること
プログラムの変更がしにくくなるこれに尽きます。
機能の改善や追加がしづらい
仕事でプログラミングをする場合、ほとんどが複数人でのチーム開発です。
ゼロから作り上げたものが世にリリースされ、機能の改善や追加をしながら、サービスが運用されていきます。
そうすると、当たり前ですが、コードを修正しますよね。そのときに、テストがないと「今まで動いていたものが動かなくなる」という自体に気づくことが難しくなるんです。
テストコードがあれば、機能を追加した後も、今まで動いていたものが今まで通りに動いていること が簡単に確認できます。
じゃあどうするか？テストを書くしかないわけです！
リファクタリングがしづらい
リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。
以前紹介した通り、プログラミングコードは適度なタイミングでリファクタリングを行なっていきます。そうしないと、読みづらくて手がつけにくいコードになってしまうからです。
リファクタリングは機能追加ではなく、あくまでもコードの整理整頓なので、今までの動作を保証しつつ修正する必要があります。
テストコードがあれば、今まで通りに動いているかが簡単にチェックできますが、ない場合は手動で全て確認し直すという鬼のような作業が待っています笑
そんな手動でチェックなんて絶対やりたくない！
まぁそう思うのが普通です。ちょっと修正しただけで、膨大な確認作業が発生してしまうようでは、おちおちリファクタリングなんてできないわけです。
じゃあどうするか？そう、テストを書けばいいんです！
バージョンアップがしづらい
このサービスはこれで完成していて、今後機能追加も一切ありません！
そんなサービスであっても、バージョンアップだけはしないといけないんですよね。
例えば、セキュリティに問題があることが発覚した gem があり、
とアナウンスされたとします。
今動かしているサービスも、セキュリティ的に問題のあるバージョンの gem を使い続けるわけにはいかないので、アップデートする必要がありますよね。
アップデートして、バージョンアップすることで今まで動いていた機能が今まで通りに動いているか のチェックをしないと、いけなくなるわけです。
テストコードがないと、やはりここも手動チェックする羽目になります。
もうお分かりだと思いますが、テストを書けばいいのです。
自動化は正義
テストコードがあれば、
- 機能の追加・修正
- リファクタリング
- バージョンアップ
の際に手動でチェックという手間のかかることをせずに、自動でプログラムの動作が正常なのかをチェックできるというメリットをお伝えしました。
実はこの「自動化」というのはプログラマーにとってとても大事なことなんです。
テストコードでのチェック方法
テストコードを書いたら、手元でコマンドを実行して確認するのが基本です。
- プログラムとテストコードを書く
- テストコードを走らせてチェックする
- 問題があるところを修正する
という手順を繰り返しながら実装を進めていきます。
ただ、テストコードが多くなってくると、テストを走らせるのにも結構時間がかかるようになっていくので、待ち時間が発生してしまう んですね。
そこで出てくるのが、CI （シーアイ, 継続的インテグレーション）ツールです。
CI によるテストの自動化
CI(継続的インテグレーション)では、開発者が自分のコード変更を頻繁にセントラルリポジトリにマージし、その度に自動化されたビルドとテストを実行します。
この CI ツールを使うと、GitHub に push した時点で自動的にテストを実行してチェックできるようになります。
CI ツールの機能はこれだけではないのですが、テストコードを書くことで、手動でテストを走らせる必要もなくなり、コードの品質を担保できるような仕組み作りができるようになるんですよね。
自動化を進めると
自動化が進むと、こんなことが起こります。
- プログラムがチェックするので、チェックミスが減る（ひとはミスします）
- ひとの負担が減り、他のことに時間が使えるようになる
テストを書いて、CI で自動化するのはその例のひとつですが、テストを書くことのメリットが大きいことは理解できたと思います。
テストの種類
まず、テストのおおまかな分類と、これから学んでいくことについて解説していきますね。システム開発では、大きく以下の３種類のテストがあります。
- 単体テスト（Unit Test）
- 結合テスト（Integration Test）
- システムテスト（System Test）
単体テスト
作成したプログラムを一つずつ単体でテストして正常に動作するかを検証するテスト
プログラムのテストでの最小単位のテストです。
Take off Rails では、単体テストを書くところから始めます。具体的には、model に書いたメソッドが正しく動いているかどうかをチェックしていきます。
結合テスト
単体テストで確認した複数のモジュールを組み合わせて不具合がないか、連結がうまくいくかを検証するテスト
単体テストができたら、それらを組み合わせて動作をチェックするのが結合テストです。
Take off Rails では、単体テストの実装方法を学んだ後に実装していきます。具体的には、controller ( request ) のテストにあたります。 API を叩いて、想定している挙動になっているかをチェックしていきます。
API の挙動をチェックするので、Rails では WebAPI テスト に相当します。
システムテスト
すべてのプログラムとハードウェアを合わせて行うシステム全体のテスト
実際に作成したアプリケーションが、正しく動くかをチェックするのがシステムテストです。
Take off Rails では、Rails はあくまでも API を提供するためのもの としているので、システムテストは扱いません。
１つの完成されたアプリケーションをテストするので、フロントエンド（HTML, CSS）と一緒にテストしてあげる必要があるんですよね。
バックエンドからフロントエンドまで、機能を一貫してテストするので、E2E（End to End）テストと呼ばれることもあります。
テストはどこまで書くべきか
一言でテストと言っても、いくつも種類があることがわかりました。
すべてのテストを、俺は書く！
と意気込む前に、テストを書く意義について、もう一度振り返ってみましょう。
テストは適切なエラーを検出するためにある
いろいろとテストを紹介しましたが、テストはサービスが正常に動くために必要な機能がきちんと動いているか を確認するためにあります。
テストはもちろん、全てしっかり書かれている方がベターではあるのですが、時間は有限です。
テストにも、優先度の高いものと低いものがあるので、できるだけ高いものを優先的に実装していくのがおすすめです。
優先順位をつけるとしたら、こんな感じです。
WebAPI テストはコスパが良い
結合テストである WebAPI テストは、Rails を JSON を返す WebAPI として扱う場合に非常にコスパがいいんですよね。
なぜかというと、万が一、途中の処理にちょっとしたミスがあったとしても、最終的に出力される結果さえあっていれば、それは大きな問題にはなりにくいからです。
単体テストが充実していて、それぞれの動きが正しくても、API に不具合があり、そもそも動きませんでした では結局ダメなんですよね。
Rails のテストの中で一番大事！
E2E テストはコスパが悪い
E2E テストは、サービスが動いているかどうかをチェックするためのトータルチェックができるので、一見 WebAPI テスト以上に必要に思えるかもしれませんが、実はコスパがすごく悪いんです。
E2E テストは、HTML 構造になぞってボタンをクリックするようなテストを書かなければいけないのですが、フロントエンドはバックエンドよりも変更が多くてすぐにテストが動かなくなってしまいがち なんですよね。
例えば、Qiita の記事詳細リンクを踏んで、想定しているページに遷移できているかを確認したいとします。
でも、見た目が大きく変わらなくても、HTML 構造が少し変わっただけで該当するリンクが見つからず、エラーしてしまう。
それが E2E テストです。
こんな理由もあって、Take off Rails では E2E テスト（システムテスト）を扱いません。
時間なくてまだ書けてないんだけど笑
なんていう会社は結構多いです。
まとめ
Rails Level.2 の初回となる今回は、「なんでテストが必要なのか」について解説しました。
- テストがないと、機能追加・修正、リファクタリング、バージョンアップといった変更がしにくい。
- テストコードを書くことで、チェックをプログラム任せにできる。
- CI ツールを使うことで、テストのチェックも自動化できる。
- テストは大きく分けて３種類あり、結合テスト、単体テスト、システムテストの順で優先度が高い。
※ テストの優先度の話は、僕がいくつか現場をみてきた上での実感なので、ひとによって意見が異なる部分です。ただ、優先度はどうしても決めざるを得ないので参考として覚えておいてください。
次回は、早速 rspec の環境構築をやっていきましょう！