TestCafeはSeleniumよりもどのように優れていますか？
TestCafeは、Seleniumでの採用を正当化するためにどのような問題を克服していますか？古いテストスーツをTestCafeに移植する価値はありますか？
TestCafeチームがSeleniumの上にTestCafeを構築することに反対した理由はたくさんあります。
まず、テスト環境のセットアップを簡素化したかったのです。 Seleniumを使用するには、目的のプログラミング言語用のWebDriverクライアントと、テストするブラウザーごとに適切なドライバーをインストールする必要があります。
かなり簡単に聞こえますが、実際には、テストを開始するのは非常に面倒です。テスト環境を大規模に構成する必要がある場合、この面倒はさらに大きくなります。ローカルCIサーバー用。
NpmのSeleniumをベースにしたnode.jsテストソリューションは多数あります。開始するためだけに、かなりの量のセットアップと構成作業が必要であることがわかります。これは、現代のWeb開発者のツールベルトの他のツールで慣れ親しんだnpm installセットアップの単純さからはほど遠いものです。
TestCafeには、TestCafeが基盤となるプラットフォームとしてSeleniumを使用した場合には不可能な機能もいくつかあります。たとえば、TestCafeはモバイルを含む リモートデバイス でテストを実行できます。これは、TestCafeがインストールされていないマシンでテストを実行できることを意味します。ブラウザでリンクを開くだけで、テストが開始されます（ホストデバイスとターゲットデバイスがネットワーク内で相互に認識している場合）。この機能を使用すると、TestCafeまたはnode.jsがまったくインストールされていないエンジニアにバグをすばやく示すことができます。
Seleniumの上に実装するのが難しいその他の機能は次のとおりです。
隔離されたテスト環境。各TestCafeテストは、新しいシークレットタブで開始されたかのように実行されます。すべてのCookieとストレージがクリーンになります。これにより、多くの定型テストコードを回避し、状態の干渉のリスクなしに同じブラウザーで作業できるようになります。これにより、今後の ロール機能 などのメカニズムを実装することもできます。このメカニズムを使用すると、さまざまなユーザーの視点からページを操作したり、テスト間でフォーム認証を簡単に実行したりできます。
暗黙の自動待機メカニズム。 TestCafeは、XHRリクエスト、ページの読み込み、ページアニメーションを自動的に待機するため、コードでそれを処理する必要はありません。