ソフトウェアテストのピラミッドを構成するすべてのタイプのテストの中で、エンドツーエンドUIテストは、管理が最も難しく、実行速度が遅く、不安定で、信頼性が低く、時にはまったく実用的ではないとさえ考えられています。ThoughtWorksのブログの最近の投稿をご覧ください。著者は、UIテストの状況について尋ねられたエンジニアリングチームからの回答を思い出しています。
「そうですね、Seleniumテストはいくつかありますが、非常に壊れやすいです。常に壊れているように見えるので、めったに実行しません。」
それだけでなく、CypressプロジェクトのチームがWebサイトに書いていることを見ると、ソフトウェアテストはソフトウェア開発者の間で好ましい評判を得ていないようです。「テストは最悪です。それはすべての開発者が恐れている部分です。」
UIテストをそれほど脆く「恐ろしい」ものにしているのは何でしょうか？ Cypressチームはまた、フロントエンドテストは過去10年間、少なくともWeb開発と同じペースでは進化していないと主張しています。
インターネットは高速化しているが、Webサイトはそうではない
まず第一に、Web開発は過去10年間でそれほど進化していません。あるいは、それは「進化」の意味によって異なります。確かに、webpack、React、ES6はありますが、httparchive.orgのデータによると、インターネットの速度が着実に増加し、ハードウェアが急速に進歩しているにもかかわらず、ページの読み込み時間は過去10年間でほぼ同じままでした。したがって、インターネットは高速化しているが、Webサイトはそうではないと言っても過言ではありません。さらに、Skypackユーティリティの背後にあるチームが指摘しているように、「Web向けに構築することはかつてないほど複雑になっています。」
これを念頭に置いて、実際にはWeb開発はそれほど進化していないと断言しても構わないでしょう。より洗練されたツールができたとしてもです。一方、フロントエンドテストは進化し、複数の分野で進化を続けており、おそらくWeb開発自体よりも急速に進化しています。
コーディングとテスト
ソフトウェア業界全体がソフトウェア開発プロセスの二元論的な見方を採用しているため、テストは開発者にとって「恐ろしい」ものです。一方には、クールなものを作ったり、最新の技術を試したりすることを常に約束されている開発者がいます。もう一方には、テストと品質保証があり、これは開発者にとって退屈で面白くないと見なされることが多いです。
フロントエンド開発が認識されているのと同じように、ソフトウェアテストが刺激的でクールであることを開発者に納得させるには、想像力を働かせる必要があります。開発とテストの間にこの二元性が存在する限り、開発者はテスト部分を恐れています（そしておそらく品質エンジニアも開発者の絶え間ない変化と洗練さへの執着を恐れています）。テストは不安定で壊れやすいままであり、全体的な品質の低下につながります。
私が示唆しようとしているのは、コーディングとテストは互いに独立して行われる2つの別々の活動ではないということです。テストは、コーディングと同じように、ソフトウェア開発の不可欠な部分です。テストは自分の仕事ではないと考えている開発者でも、何らかの形のテストを行っています。彼らは単に自動化された方法で行っているのではなく、手動で、退屈で、ややランダムな方法で行っています。
UI自動化のためのNightwatchの使用
約10年前、Node.jsがリリースされたとき、JavaScriptを使用してエンドツーエンドテストを行うためのツールはほとんどありませんでした。存在するツールは、効果的な方法でセットアップして使用するためにかなりの労力を必要としました。しかし、現在では、Node.jsを搭載したUIテストフレームワークがいくつかあり、それらはすべて高速なインストールとJavaScriptで記述された安定したテストを提供することを約束しています。
UI自動化プロジェクトのセットアップに数時間、あるいは数日も費やさなければならなかった時代は確かに過ぎ去りました。 Nightwatchを使用すると、Selenium GridとBrowserstackの組み込みサポートを含め、Chrome、Firefox、Safariを使用したテスト自動化プロジェクトを1〜2分で稼働させることができます。追加のサービスも簡単に追加できます。
しかし、テストはまだ壊れやすい、または信頼性が低いでしょうか？そうです、UIテスト、特にSeleniumテストで使用される2つの最も一般的な形容詞です。 Nightwatchには、要素の暗黙的な待機、失敗したアサーションの自動再試行、失敗したテストケースの再試行、ネットワークエラーの再試行など、テスト実行における脆さと不安定さを軽減するためにオープンソースフレームワークから期待できるほぼすべてが揃っています。私たちの計画は、不安定さを検出して軽減しようとするだけでなく、それを不可能にすることです。
フィードバックループとは何ですか？
フィードバックループは、計画、コード、検証、終了という以下の手順で構成される反復的なアクティビティです。コード変更を計画し、実装し、結果が意図したとおりであるかどうかを検証するプロセスです。
フィードバックループは、ソフトウェア開発とその先、あらゆる場所に存在します。私が初めてフィードバックループについて聞いたのは、2010年にjQueryカンファレンスでプレゼンテーションを行った同僚からです。フィードバックループはアジャイルソフトウェア開発手法では一般的な概念ですが、制御理論、生物学、数学、エンジニアリングなどにも同じ概念が見られます。地球の気候システムでさえフィードバックループを持っています。
認知科学の創設者の1人である「Plans and the Structure of Behavior」（1960）は、フィードバックループの初期の形態を人間の行動の基本単位として導入しました。著者は、TOTEユニットを作成する以下の手順を特定しました。テスト-操作-テスト-終了。彼らが説明したように、「最も弱い形式では、TOTEは、生物が行う操作は、さまざまなテストの結果によって常に導かれると単に主張しています。」1
フィードバックループは、神経系の基本的な構成要素です2。これは、プロセスでテストを行っていないと言うすべての開発者でも、何らかの形のテストを行っているという、私が以前に指摘した点につながります。新しい機能の実装であれ、バグの修正であれ、私たちが完了しなければならないタスクは、少なくとも1つのフィードバックループ（TOTEユニット）を伴い、通常は複数回の反復が行われます。
タスクの完了
タスクの例を次に示します。Browserstackは、複数のデスクトップブラウザとモバイルブラウザを含む分散クラウドインフラストラクチャでテストを実行しようとしているNightwatchユーザーに人気のある選択肢です。
あなたがBrowserstack Automate UIダッシュボードを構築している開発者であり、あなたのタスクが新しいNightwatchテストをリストにリアルタイムで表示することだとします。
上記のTOTEユニットを考えると、*テスト*フェーズはかなり複雑になり、機能が正常に実装されているかどうかをアサートする前に必要な、いくつかの異なる操作が含まれます（ループを停止する条件）。そこにはいくつかのサブフィードバックループさえあります。
変更を実装したら、検証プロセスの次の手動手順を実行する必要があります
- ローカル開発サーバーが実行されていることを確認する
- ローカル開発バックエンドに対してサンプルテストスクリプトを実行する
- ブラウザを開き、ローカル開発URLに移動する（またはページをリロードする）
- テストスクリプトがダッシュボードリストに表示されることを確認する
フィードバックループを短縮する方法
実装フェーズは反復ごとに異なりますが、テストフェーズはかなり固定されており、毎回同じ手順とほぼ同じ量の労力が伴います。したがって、それを削減できれば、実行が容易になるだけでなく、時間も短縮されます。
ありがたいことに、今では準備フェーズに含まれるすべての手動手順を自動化することができ、条件が満たされたかどうかを確認するためのテストアサーションを追加することもできます（実行されたテストスクリプトがダッシュボードリストに表示される）。すると、フィードバックループの実際の*テスト*フェーズは、この新しく作成された自動スクリプトを実行するだけになります。
デモプロジェクト
まだ納得できない場合は、Githubで入手できるこのデモプロジェクトが役立つかもしれません。プロジェクトには、上記で説明した実験のすべてのコードが含まれています。
実際に動作する例を用意するためにパブリックURLをここに含めましたが、もちろん実装フェーズでは、代わりに開発サーバーが使用されます。
メインのエンドツーエンドテストは次のとおりです。
- browserstack.comサービスに対してログインを実行する
- 後続のテスト実行のセッション状態を維持するために必要なCookieを保存する
- 子プロセス内で2番目のNightwatchテストを開始する
- 2番目のテストがBrowserstackダッシュボードのリストにあるかどうかをアサートする
この手法を使用することで、フィードバックループが短縮されるだけでなく、タスクが完了したときにエンドツーエンドテストも実行できるようになり、リグレッションテストと継続的インテグレーションの目的で使用できます。