ヘッドレスブラウザとSelenium3

今回もQiitaネタです。

--headless時代の本命？ Chrome を Node.jsから操作するライブラリ puppeteer について．．．という記事を拝見しました。

そして、今回も社内（協力して頂いているパートナー会社の方とか、フリーランスの方を含む）コミュニケーションツールとして
利用しているslack上で呟いてみました。

　筆者 [14:42]
　▼UI含めたテストでは今後の必須知識！、なのかな．．．（headless Browser）
　レンダリング無しならテスト速いんだろうなあ．．．
　(上記URLを貼り付け)

　○○○ [14:42]
　現場(客先)のslackにも全く同じ記事が貼られてた。

おおー！、見事に社外にいるメンバーからの即時応答！（DM：ＤｉｒｅｃｔMessageじゃないのに...）

やっぱり自動テストには関心が行きますよね。
レスの有った"○○○"さんは、自社企画・展開のサービスを開発してビジネスを立上げ中の顧客先で開発作業を支援してるメンバーです。

UIの自動テストは、従来だとWebブラウザを起動して画面操作のイベントを起こさせて...と、フツーにWebブラウザの画面が
勝手に（＝指定通りに）起動されてパラパラと画面遷移していきます...
が、実画面を表示する時間もかかるので、レンダリング時間も自動テストの中に含まれてしまいます。

結果、CI・自動テストは良いんだけど、"とにかく実行に時間が掛かる"のがネックでした...。
実行時間のコストを考えて（勿論、UIテストコード作成・メンテの必要性・メンテコスト・適用価値の総合判断もしますが）
画面展開を伴うテストは範囲を限定しようという現実的な制約というか、技術的な圧力が掛かってしまうケースも多々あったかと思います。

UIの自動テストを行うPCのグラフィックス系ハードウェアも高性能なパーツにしたりとか...
でも、ヘッドレスブラウザなら格段に効率が上がるだろうと思われます。
（実証していないので断言できないところが、情けないと言うか申し訳ない所ですが...）
Selenium3も、是非使ってみたい！

変更や、様々な部分での"必要と判断される変更"を、躊躇せずに行える（少なくとも自動テストの所要時間を余り気にせず）
状態に置くべきですよね。
（勿論、開発対象の各種特性によって判断や基準は違ってくるとは思いますが）

まあ、ヘッドレスブラウザも人間（組織）が作ったモノなので、何処まで信頼できるかは分かりません。

しかし、存在を知りながら手も出さず・評価もせず、では、改善の可能性にも至りません。

小さなチケットを切ってでも、簡易評価をして環境構築・テスト・評価をしてみるべきだよねーと思います。
勿論、得られたナレッジはslack上（＆その他の社内的な手段を使って）で共有します。

その為には、評価してもらう時に、メモでも良いから必ず要点を残してもらうこと！、ですよね。
チケットなら、それに紐付いて残るし、別枠でナレッジ集約のページなど（プロジェクト／プロダクト横断的なナレッジ集約ページ）
にも掲載していけますし。

★クリック１つでブログランキングにご協力戴けます！ m(_ _)m