自動テストとの向き合い方
はじめに
初めまして！
株式会社おてつたびでフルスタックエンジニアをしているぶりぼんと申します。主にフロントエンド領域を開拓しており、ReactやTypeScriptが最も得意です。
今回は、おてつたびの自動テストとの向き合い方に関してお話しします。
フロントエンドのテスト環境はまだ準備中であるので、バックエンドの自動テストに関して言及します。
テストコードの書き方というより、テストコードを書いた結果としてどのような恩恵があったか、といった趣旨の記事になっております。
自動テストの導入
導入前のテストとの向き合い方と課題
テストコードを最初に書き始めたのは、2021年の夏頃です。
それまでは、一切テストコードがない状態であり、実装しながら前のコードとの差分を確認しつつ、実装後はローカル環境で想定ケースを手動でテストを行なっている状態でした。
2021年の春以降に開発メンバーが増えたこともあり、夏や秋ごろから、少しずつ本番環境における不具合が散見されていました。
テストコードがないコードでは、不具合が発生しやすいということは自明ですが、以下のような課題も発生していました。
- テストコードがないゆえに安心してコードの追加ができない
- リファクタリングを行ったり、実装を少し変更したりするだけで、再度手動テストを実施する必要がある
- テストがないことでどこまでテストの担保ができているか分からず、レビューのコストが高くなってしまっている
上記の状態に待ったをかけるためにも、自動テストを導入することに決定しました。
自動テストの導入
始めの記事でも記載した通り、おてつたびはRuby on Rails を使って開発をしています。
テスティングライブラリはRSpecを選択し、テストデータ生成のライブラリはFactoryBotを選択しました。
Railsで開発をしている現場では、お馴染みのテスト環境ですね。
いきなり現存するコードや、実装する全てのコードに対してテストコードを書くことは、ナンセンスだと思っています。
そのため、おてつたびでは以下の2つのルールを定めてテストコードを書くことにしました。
- 新しく追加するクラスに対してのみテストを書く
- ビジネスロジックを司るクラスに対してのみテストを書く
自動テストの導入直後
RSpecは他のフレームワークのテストツールと比べて、利便性は高いのですが、一方で独自性の高い書き方を強いられます。
そのため、まずはテストコードの書き方を学習することから始めました。
また、テストコードにおけるコーディング規約をどうするかにも非常に悩んだことを覚えています。
さらに、設定不足により開発環境でテストが実行されない、開発環境で実行できてもCI環境では実行されない、といった問題も発生していました。
やっとのことでテストコードを書き上げましたが、すぐに効果が上がるわけではありません。
むしろ、費用対効果が高いなくらいに思っていました。
自動テストを導入してから数ヶ月
不具合が大きく激減したかと言われれば、正直あまり目に見える形で表れていません。
ただ、実装中に不具合や漏れているケースを発覚できたり、不具合が起きた際にどこまでのケースなら担保しているかが分かったりというメリットはありました。
ソフトウェアエンジニアとしては最も嬉しいメリットは、書きながらいけていないと思ったコードを、思い切ってリファクタリングすることができるようになった点です。
また、他の開発者のコードでも、テストコードを見ることでどのテストケースが担保されているか、どのテストケースが漏れているかということが分かるようになりました。
今までレビューする際は、ブランチをチェックアウトして手動テストを行なっていましたが、ソースコードレベルでテストケースの漏れを発見することができ、レビューのコストも下がったのではないかと思っています。
カバレッジレポートの導入
自動テストを導入してからはチーム全体でテストコードを書くことが当たり前になりましたが、実装者によってテストケースがバラバラになっていました。
例えば、条件分岐がや想定ケースが複数あるにも関わらず、正常系と異常系のテストケースを一つずつ書いているだけという場合です。
テストコードを導入した開発チームに良くありがちな、とりあえずテストコードだけを書いて安心しているというパターンですね。
上記の状況を変えるため、また裏目的として内部品質を数値で可視化するためにも、カバレッジレポートを導入しました。
Simplecovというライブラリを使って、カバレッジレポートの出力を行なっています。
Simplecovは非常に便利で、モジュールや責務（ControllerやModel）毎にカバレッジ率を出してくれます。
これにより、現状のテスト対象であるビジネスロジックのモジュールでは、カバレッジ率が何%かというのを確認できたり、付随して他のモジュールのカバレッジ率も確認することができました。
また、カバレッジレポートの出力と同時に、Codecovというツールも導入しました。
このツールにより、時系列でカバレッジ率がどう遷移したかを確認できるようになりました。
目に見えて数値が良くなっているのを確認でき、テストを書くモチベーションが上がりますね。
このツールの導入と使い方に関しては、また別の記事でお話しします。
ちなみに、カバレッジレポート導入直後のおてつたびのカバレッジ率は、20%にも満たない結果でした……。
今後の自動テストとの向き合い方
テストコードを書ける環境が整い、カバレッジレポートも出力し、自動テストの環境という観点ではそこそこ充実していると言えるのではないでしょうか。
一方で、まだまだ課題はあります。
カバレッジレポートの導入の箇所でも述べた通り、開発者によってテストコードの粒度がバラバラです。まずはここから見直さなければなりません。
一つの解決策として、カバレッジ率がX%以上の場合だけコードを出荷するということが挙げられます。
また、カバレッジ率が基準に達しており、テストケースを充分に網羅していても、そもそものビジネス要件を満たしていないという場合もあります。
テストケースがビジネス要件を満たしているかというレビューや、レビューを行うためにテストコード自体をクリーンに保つという仕組みも必要です。
終わりに
株式会社おてつたびでは、一緒に働く仲間を募集しています！
日を経つごとに、少しずつプロダクトは良くなっていますが、まだまだ課題が山積みで、エンジニアの手が足りていません。
本記事では、今まで行ってきたWeb開発における話をしましたが、iOSアプリの開発を行っており、初期リリースを控えております。
第一号となるiOSエンジニアを募集しておりますので、まずは興味がある方は気軽にお話をしましょう！
もちろん、Webフロントエンドエンジニア、Webバックエンドエンジニアも募集しております。
引き続き、地域とのご縁を紡げるサービスであり続けるために、多くの方に興味を持ってもらいたいです。
本記事をご覧になって少しでも興味が湧いた方は、以下のリンクをチェックしてみてください！
Discussion