・RoRのテストについて自分なりの解釈を紹介
・簡単そう？に思えて奥が深いテスト
何とか少しずつRuby on Railsの勉強を行っています。
今回はテストについて学びましたので自分なりの解釈を紹介したいと思います。
Rubyはテストフレームワークが予め用意されている影響なのか、テストについて紹介している教材が多い印象です。
良いことだと思います。
過去の学習用のアウトプットは下記となります。
Ruby on Railsでよく使われるテストフレームワーク
Minitest
Railsには「Minitest」と呼ばれるテストフレームワークは予め用意されています。
昔Javaを触っていた身としてはMinitestは一般的なテストコードのイメージが強いです。
MinitestはRailsテスティングガイドでも紹介されているほど、Rails（Ruby）では広く使われています。
Rails テスティングガイド
https://railsguides.jp/testing.html
しかし、一般的なテストコードイメージであるMinitestだと設計書との関連性が薄く感じてしまい、「どのような仕様を担保するテストなのか」が分かりづらくなります。
お客様の受入要件上、カバレッジ・テストケース数・E2Eテストでは測れない部分もあるためMinitestもやれるならやった方が良いと考えています。
しかし、「仕様に即した動きなのかを担保する」テストであるならば下記のRSpecを使った方が良いです。
RSpec
RSpecはGemの追加が必要ですが先ほどのMinitestであげた「仕様に即した動きなのかを担保する」テストには強く発揮します。
少し癖があるため慣れるのには苦労すると思いますが慣れてしまえば、仕様書とテストコードの関連性がイメージ出来やすくなると考えています。
次章からはRSpecやMinitestも含めたテストコードを書くメリット・デメリットについて紹介します。
テストコードのメリット・デメリット
メリット
- 長く続く場合はコスト増に歯止めを掛けられる
- 環境バージョンアップやリファクタリングに強い
- 変更時のフットワークを軽く出来る
- ドキュメントや証明書代わり
- コード粒度の均一化
「長く続く場合はコスト増に歯止めを掛けられる」は、機能改修や追加時のテストを行う場合、既存機能に影響が無いこともテストで行います。
そうなると、機能が増えれば増えるほど徐々にテストに掛かるコストは増えてしまいます。
しかし、テストコード自体を成果物とすることで機能が増えるときの影響確認テストを自動化しそこに掛かるコストを使わずに済みます。
一見するとコストが減ると思われがちですが、始まりの段階ではテストコードのコーディングコストは、手でテストするときよりコストが掛かります。
テストコードを書くことでテストのコストはある程度で止まりますが、そこに至るまでのコストは普段より掛かるためお客様に納得いただける説明をするためには、PMの腕の見せどころです。
「ドキュメントや証明書代わり」については主にRSpecなどの「仕様に即した動きなのかを担保する」テストに強い場合はこれに繋がります。
「コード粒度の均一化」というのは、無駄な処理を無くせることです。
テストコードを先に書く「TDD」の手法を用いれば検証時作ったコード（とりあえず作って動いたからそれを使い回す的な）も無くなり、管理しやすいレベルのコードに収まるのではないかと思います。
デメリット
- 習熟に時間が掛かる
- 損益分岐点の感覚が難しい
「習熟に時間が掛かる」とは、モチベーションの存在が大きいです。
学習するときは「○○を作りたい」にフォーカスしそれが目的に近いもののため、個人的にはテストは疎かになりがちです。
そういった方がチームにいる状態で進むと理想形からは少し外れてしまいコストが嵩むかと思います。
TDD手法にしてやらざるを得ない立場になればいずれ練度が増すと思いますが中々難しいと考えています。
「損益分岐点の感覚が難しい」はメリットで書いた「コスト」についてのデメリットです。
テストを何回か行う状態であればコストは落ち着きいずれ益に繋がります。しかし世の中には1度作ったものは1度テストするだけで終わる機能もあります。
そういったことが分かるなら、テストコードを書かずに手動テストで終わらせた方が良いです。
ですが、予定が変わりメイン機能になることも多々あります。その部分に対するテストコードへの切り替えるタイミングが難しい印象です。
そういった場合（サブ機能がメインに昇格）はイレギュラーパターンかもしれませんが、パターンが多いロジックやお客様の重要度が高い部分は、そこだけでもテストコードを書いた方が良いと思います。
