著者は、Node.js に依存せずにフロントエンド JavaScript を記述することを目指しています。直面した大きな課題は、フロントエンド コードの効果的なテスト方法の欠如です。Playwright を使用した以前の試みは遅く、Node.js が必要であると判断されました。これを解決するために、著者は Alex Chan によるミニマリストなブラウザ内単体テストフレームワークに関する作業に触発され、テストをブラウザタブ内で直接実行することを検討しました。Chan のアプローチは単体テストに焦点を当てていましたが、著者は Node.js ビルドプロセスなしで Vue コンポーネントのエンドツーエンド統合テストを実行することを目指しました。著者は QUnit をテストフレームワークとして使用し、デバッグのための「rerun test」ボタンを高く評価しました。プロセスには、Vue コンポーネントをグローバルに公開し、それらを非表示のオフページ div でレンダリングする mountComponent 関数を作成することが含まれていました。フィクスチャデータは、専用のエンドポイントへの POST リクエストを介してデータベースをリセットすることによって管理されました。基本的なテストでは、コンポーネントをレンダリングし、そのコンテンツをアサートしました。遭遇した主な問題には、非同期操作の完了を待つことが含まれ、waitFor() 関数の開発につながりました。待機する正しい要素または条件を特定することは困難であることが判明し、より信頼性の高いアプリケーションのリファクタリングが提案されました。著者は、要素の識別のために CSS クラスを追加することも実験しましたが、Testing Library のようなライブラリは、よりアクセスしやすいアプローチを推奨していることに注意しました。フォーム処理は、値を単純に設定するだけでは不十分であり、関連する DOM イベントをディスパッチする必要があったため、困難をもたらしました。これは、UI テストライブラリがそのようなタスクを簡素化する理由を浮き彫りにしました。テストカバレッジは、Chrome の組み込み開発者ツールを使用して部分的に評価されましたが、プロセスでは、バンドルされた JavaScript で機能するために特定の構成とアクションが必要でした。学習曲線にもかかわらず、著者はこの経験を楽しんでおり、フロントエンド プロジェクトの自信のあるテスト スイートを構築することに楽観的であることを表明しました。また、ブラウザのみの実行と互換性のある UMD ビルドを提供する Testing Library のようなライブラリのさらなる調査を検討しており、ブラウザ中心のテストを CI 環境に統合する方法を検討しています。