投稿日
この記事は更新から7年経過しています
結合テスト自動化事例
もくじ
- はじめに
- 目次
- canalのシステム構成
- canalのシステム全体構成
- canalで採用しているソフトウェア
- ScooldとParaの役割分担と構成
- 自動テスト導入の背景とアプローチ
- サマリ
- 背景
- 自動テスト導入に向けて
- E2Eテストの導入
- サマリ
- 背景・課題
- 目的・狙い
- テスト対象の検討
- アプローチ
- ソフトウェア選定
- テスト実行環境
- テスト観点
- テストコード解説
- 苦労した点
- Controllerのテストからのフィードバック
- Controllerのテストの導入
- サマリ
- 背景・課題
- 目的・狙い
- Scooldのクラス構成
- テスト対象の検討
- アプローチ
- ソフトウェア選定
- テスト実行環境
- テスト観点
- テストコード解説
- 苦労した点
- 自動テストを導入しての所感と今後
- 自動テスト導入にあたっての感想
- 残課題と今後の改善ポイント
自動テストを導入しての所感と今後
このページでは、canalに自動テストを導入した際に得られた感想や、今後の取り組みについて記載します。
自動テスト導入にあたっての感想
以下に、canalに対して自動テストを導入するにあたって、得られた感想や悩んだポイントについて記載します。
繰り返しとなりますが、この取り組みは「すでに稼働済みのシステムに対して、自動テストを導入する」という点に注意してください。
下表はFintanで公開されているテスト種別&テスト観点カタログの機能テスト部分を抜粋し、取り組み実施前後でどう変わったかを示したものです。
この取り組みで、E2EテストやControllerのテストを書くためのライブラリやテストコードの構成の決定、Paraをテスト内で起動させて組み込んで使うなどの方法を確立しました。これにより、今後E2EやControllerのテストを拡充しやすい状態にできました。
開発フローは、テスト導入前後で以下のように変更し、ControllerやE2Eテストを必ず実装・実施するようにしています。
テスト導入前
- 機能を実装
- 個人のローカル環境や開発環境にデプロイ
- 打鍵でのテスト
テスト導入後
- 機能を実装(
Controllerのテストも同時に実装・実施) - 個人のローカル環境にデプロイ
- E2Eテストの実装・実施
- リポジトリへのpushを契機に以下をCIサーバーにて実施
- ビルド、
Controllerのテスト - 開発環境へデプロイ
- 開発環境に対するE2Eテスト
- ビルド、
- 開発環境での打鍵テスト
E2EテストとControllerのテストにより、canalの主要なユースケースの動作を常に確認できるようになりました。これにより、機能追加や修正時に安心して開発できるようになったと感じています。
各個別のページ(E2Eテストの導入,Controllerのテストの導入)で、それぞれのテストに対する取り組みにおいて、検出した課題を記載しています。
技術的な課題は、それぞれ個別に取り組み、そのテストの範囲内で解決しています。内容については各個別のページを参照してください。テストの方針、設計面についてはテストを作成するメンバー間で認識齟齬が発生しやすく、テスト範囲の設定に悩むことが多くありました。 この点については、その傾向が検出される度に繰り返し、以下の観点で方針を再確認しました。
- このテストではなにを確認すべきだったか
- 他のレイヤーのテストではなにを確認していたか
観点は、テスト種別&テスト観点カタログを利用すると網羅的に整理できるので、参照しながら自動化するテスト範囲を整理すると良いでしょう。
残課題と今後の改善ポイント
開発フローは整ってきましたが、Controllerのテストの拡充に課題が残っています。
Controllerのテストは、基本的にControllerの入出力に着目するものの、処理によっては内部の動作に踏み込む必要が出てきます。 しかし、ScooldではビジネスロジックがControllerに集中しているかUtilsに散在しており、各クラスに対するテストを作成しづらい構成になっています。そのため、ビジネスロジックを単体で確認することが困難になってしまっています。
Controllerに対するテストの仕組みは整ったので、今後はテストしやすいようにリファクタリングすることで開発速度を上げていくことが改善ポイントとなります。
canalテスト自動化導入事例についてのドキュメントは、このページが最後です。
この事例のドキュメントのトップページに戻る場合は、こちらから。

