エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

テストを整備するよりもアーキテクチャを変更するほうが効果が高そうと思った話

2月の半ばに、これまで3年弱携わらせてもらったプロダクト/チームを離れて、新しいプロダクトを担当することになりました。

プロダクト面での一番大きな違いは、これまでは主にデータ更新/参照系のAPI(HTTPでコールして、JSONとかXMLとか返す)ばかりを担当してきたのですが、今回担当させていただくことになったプロダクトはいわゆる普通のWebアプリケーションで、「画面」があります。

これまでは担当プロダクトがAPIだったので、EndToEndテストの整備もある程度いい感じにできてきていて、リグレッション系の不具合はほぼ0!という素晴らしいプロダクトとチームを作ってくることができました。

しかし今回、テストすることが難しい「画面」をサービスとして受け持つことになり、どうやって品質を保っていこうかなぁ… と思っていた矢先、早速、リグレッションにあたってしまいました。

ちょっと前の案件で、直さなくていいところまでJSPを直してしまっていたそうです。

ロジック周りがどれだけちゃんとしていても、最後の最後にViewでバグられたら回避方法無いじゃん… と悩みました。

エンドツーエンドテストで細かくテストできるか

ここで一旦、Seleniumなどのツールでで細か目のエンドツーエンドテスト(=イメージ的には画面レベルのユニットテスト)と思いました。

ちょうど一ヶ月ほど前にGebというものを覚えたこともあり、GebというかSpockのデータテーブル機能が、いろんな組み合わせのテストケースを並べるにはイケそうじゃん!と思ったのですが…

 

ダメだこれ、遅すぎる。

 

メンテナンス性がー とか HTMLが古くてタグにIDすら振られてねー

 

とか言う以前に、自分のやろうとしているテストをやろうとしたら、どれだけハイスペックなマシンを使っても埒が明かねーなこれ、という結論に至ってしまいました。

そんなのよりアーキテクチャ変更なんだろうな

結局Viewに近いところのバグを減らすためには、Viewにロジックを持たせないことなのだろう
という結論に至りました。

複雑なロジックはAPI化してそこのE2Eテストを充実させるとか、JSPなんぞ使わないでテンプレートエンジンを使うとか。