脳死してはいけないし、想像力が不足してもいけない

• 脳死：特に考えずに何かを行うこと。意図を失ってしまった従前踏襲とか。
• 想像力不足：考えて何かを行うが、その考えが足りていないこと。このプロセスいらなくね？って取っ払ったら大事故起こすとか。

普段は脳死ダメゼッタイ！って思いながら仕事してるのだけども、
経験的には想像力不足でしでかす方が大事故に繋がることが多い。（脳死は茹でガエル的にダメになっていく感じなので、短期的には脳死の方がまだマシ、とも言える）

何かを変えるときに、自分は限界まで想像力を働かせただろうか？
必要性を感じられないとき、ムダだと思うとき、それは自分が無知だからそう思っただけじゃないだろうか？

ってことを想像しておくことが大事。

数値だけの目標管理は危険

最近ふと思うことがあったので。

普段自分たちのやっていることを透明化、可視化しようとすると、数値化は切っても切り離せない。 数値化するので異常が起きているのか気づくし、数値化するから因果も見えやすくなるものも多い。

ただし、数値は万能ではない。 特に、単一数値指標を目標だけにして行動しているときは危ない。 （QCDなんて本当はない、上位の単一指標に集約されるはず、というのはその通りなのだけど、それで世の中がうまく回るか、というのはまた別な話。）

目標管理するときは、バランスの取れた、時には相反する数値指標を入れよう。 数値指標だけではなく、定性情報も入れよう。 それでいて、物事をもっと見えやすくするための数値化は続けていこう。

自分たちは日々色んなこと気づいているはずなんだから。

テストツールGaugeではページオブジェクトはアンチパターン？

はじめに

これはRecruit Engineers Advent Calendar 2019の5日目の記事です。 本日はテストツールGaugeについてです。

同僚のマネージャーさんとよもやましていたら、「受入テストをGaugeで書いてみたい」という話が出ました。 ひとまず宗教上の理由でGebをおすすめするわけですが、Gaugeは触ったことがなかったので触ってみました。

Gaugeとは

Toughtworksが開発している受入テストのためのテスト自動化フレームワークです。

https://gauge.org/

日本でも利用例があるようです。例えば、 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で遊ぼうと思っていたら気づいたらページオブジェクトパターンの設計議論に行き着いたお話でした。