テストツールGaugeではページオブジェクトはアンチパターン？
はじめに
これはRecruit Engineers Advent Calendar 2019の5日目の記事です。 本日はテストツールGaugeについてです。
同僚のマネージャーさんとよもやましていたら、「受入テストをGaugeで書いてみたい」という話が出ました。 ひとまず宗教上の理由でGebをおすすめするわけですが、Gaugeは触ったことがなかったので触ってみました。
Gaugeとは
Toughtworksが開発している受入テストのためのテスト自動化フレームワークです。
日本でも利用例があるようです。例えば、 https://speakerdeck.com/takayukihayashi/gaugeniyorue2etesuto
早速使ってみようとすると？
というわけで、早速GaugeとGebを組み合わせて、WEBシステムの受入テストを試しに書いてみようとします。 まずはGaugeの利用法を知りたいなと思い、公式githubに乗っていたサンプルプロジェクトを眺めつつドキュメントを読んでみて動かしてみることにしました。
https://github.com/getgauge-examples/java-maven-selenium
と、ここでびっくり。このサンプルPage Ojbect Pattern使ってない。
画面遷移に対応するためにどうしているかというとWebDriverをstaticインスタンスとして保持するDriverオブジェクト経由で使いまわしています。 WebDriverインスタンスの生成は、Gaugeの機能である@BeforeSuiteでテストスイートが走る前に行なっています。 Gaugeではこういうお作法なの？？と思って調べていくと、他のサンプルにも出会います。
https://github.com/getgauge-examples/java-gradle-selenium
そのReadmeには刺激的なメッセージが
Deprecation notice Do not use this sample. It's a reference on why page objects will burn your house. Gauge recommends not using page objects. Refer https://github.com/getgauge-examples/gauge-active-admin-example-maven and our blog
なんと、やはりページオブジェクトを使わないことがおすすめされていました。 Gebはページオブジェクトフレンドリーなフレームワークなので、とっても相性が悪そう。。 実際にGebと組み合わせて見ようと試みたのですが、Gebらしいメソッドミッシングをふんだんに利用した書き方だとDriverのハンドリングがかなり難しく、専用のアダプターが入りそうな感じでした。
今回は時間がないのでそのアダプター作りは今後に回して、 このエントリーではなぜページオブジェクトを利用しないのかという意図を探りに行きます。
そうすると公式ブログにその説明エントリーがありました。
https://blog.getgauge.io/are-page-objects-anti-pattern-21b6e337880f
明確に「ページオブジェクトアンチパターン」と書いてありましたね。
すごくざっくりいうとその理由はUIエレメントを基準にクラス分けをしてしまうのは、単一責任原則に反する（ログインの処理と検索の処理が混ざったりしてしまう）ということで、その対策として、「関心事」ごとにクラス設計するのを勧めています。 これにより、Gaugeではページオブジェクトを利用する場合に比べコードを40%削減しているとのこと。 Gaugeが
Less Code, Less Maintenance, More Acceptance Testing
という謳い文句をつけていることはこう言った部分にも出ているんだな、と感心した次第でした。 ただStepから定義されたテストケースに直接エレメント操作が書かれる可能性はあり、結構気をつけないとメンテコスト取られちゃうだろうなぁ、と想像しています。
ちなみに、Gebが微妙ならせめてGroovyで書きたいな、と思っていたら、ちゃんと公式がgroovyのexampleも乗せてくれていました。 （ただしちょっと古いものなので、このexampleはページオブジェクトパターンで書かれています。）
というわけで、GaugeとGebで遊ぼうと思っていたら気づいたらページオブジェクトパターンの設計議論に行き着いたお話でした。
