全4792文字
PR

落とし穴3:テストコード量が爆発的に増えて負担になる

 CIを導入すると、膨大なテストコードに押し潰される恐れがある。そもそもCIでは、ソースコードとともにテストコードを用意する必要がある。しかし、ソースコードに変更があると、そのつどテストコードも変更しなければならず、これが開発スピードを阻害する大きな要因となる。SCSKのある開発基盤チームも、この問題に長年悩まされた。

 SCSK AMO第二事業本部先進開発部企画開発課の堀井大砂シニアプロフェッショナルITアーキテクトらが手掛けるのは、開発・実行基盤のPaaS「FastAPP」だ。サービス開始は2011年。それから毎年マイナーバージョンアップがあり、現在は6バージョン前まで遡って保守しなければならない。さらに、不具合があった場合は1カ月以内に改修することを社内外に掲げている。

 開発スピードを上げるために、設計・実装・テストを短い期間で繰り返すアジャイルを早くから採用してきた。作業を自動化するためにCIツールのJenkinsも導入。テスティングフレームワークの「JUnit」を使い、修正に伴う動作確認の自動化も実現した。

 ところが、問題になったのはテストコードが爆発的に増えたことだった。「バージョンが上がるにつれて、テストコードのメンテナンスが追い付かなくなった」(堀井氏)。それまで1週間以内で対応していた不具合修正が、1カ月程度まで延びてしまった。

 特に負担になったのが、画面の遷移や処理を確認するUI(ユーザーインターフェース)テストだ。自動テストツールのSeleniumベースの「Geb」を導入したが、修正のたびに画面を操作してテストコードを作成する作業に振り回された。その後、テストコードを修正して効率化を図ったが、テスト項目とテストコードの多さに現場は翻弄された。

 そこで堀井氏らは、テスト項目とテストコードの関係に着目し、テストコードの爆発を解消する策を検討した。

爆発するテストコードを減らす
爆発するテストコードを減らす
[画像のクリックで拡大表示]

 対策は、思い切ってある分野のテストはしない、というものだ。具体的には、画面の裏側で動作する処理については、PCとスマホで動作が同じ点に着目。この場合、PCのみでテストし、スマホ版ではテストしないように改善した。「例えばデータのアップロード処理などは、PCもスマホもロジックは同じ。これを別々にテストしなくても品質を維持できると判断した」(堀井氏)。

 もちろん全てのスマホ版のテストを回避したわけではない。スマホ固有の画面表示などに関するテストはPCとは別に実施している。

■変更履歴
公開当初、日立ソリューションズのグループマネージャの名前を「髙月祐二」氏としていました。お詫びして訂正します。本文は修正済みです。[2019/2/1 14:30]