⚙️フロントエンド開発のためのテスト入門 - サンプルの紹介 -2023/04/06に公開3件StorybookJestPlaywrighttechDiscussionShota Tamura2023/05/22書籍拝読いたしました。あいまいな知識が線で繋がり、今後に大いに役立ちそうです。ありがとうございます🚀 もし差し支えなければ、一点ご質問させていただいてもよろしいでしょうか🙏 現在、Unit Test と E2E Test の中間にある、Integration Test を充実させるのが一番効果的だよ、という世の流れだと理解してます。 このIntegration Testを書く手法として、本書籍では Jest + React Testing Library を活用されていたと思います。一方で、もしかしてPlaywrightでも、わりと似たようなことができるのではないか？という個人的な感触がありました。 たとえば、アサーションなどはどちらでも同じようなAPIが用意されていそうでした。 特定のテキストを持つ 特定のCSSが適用される URLに特定のQuery Stringをもつ また、アクションもほぼ同等のものがあるかと思います。 クリックする 文字を入力する inputで画像ファイルを選択する 今後、当方は画面単位でのざっくりした統合テストを書いていこうかと思っており、JestでやるかPlaywrightでやるか迷っています。 VRTが簡単にできたり、画面上で視覚的なデバッグができることを考えると、Playwrightを選択したい一方で、例えばフォームで送信されるデータの精緻な検証などには向かないのかなと思ったりもしており、迷っています。 このあたりどう感じておられるか、ご意見伺えますとありがたいです🙇♂️ Takepepe2023/05/22読んでいただきありがとうございます！ 「Integration Test（結合テスト）が何をさすのか？」というのは、文脈によって人それぞれです。拙書では、インタラクションを伴うものは、テストツールを問わず結合テストと称しています。重要なのは「何をテスト対象とするのか？」ということです。 おっしゃるとおり Playwright でも、結合テスト（機能テスト）ができます。このとき判断基準になるのが「Jest + Testing Library でも同じテストを書くことができないか？」という点に着目することです。 Jest + Testing Library の場合、jsdom という仮想ブラウザ上でテストを実行します。jsdom は実行速度が早い反面、完全にブラウザを再現しきれた環境ではありません。そのため「このテスト対象は jsdom では再現不能だから、Playwright で書こう」という判断になります。 書籍第7章で取り上げているテストは概ね、jsdom で実行できる結合テストになります。画面間を跨ぐ機能、例えば「A画面->B画面->C画面、というような流れでしか再現しない機能」をテストする場合は、Playwright で書くことになります。（ただし、こういった機能はまれで、localStorage を使った機能などです） また、Playwright はブラウザを起動するため、実行速度が遅いです。そのため、はじめのうちはあまり気にならないかもしれませんが、テストが充実してくると「CI待ちでマージするのに数十分待たなければいけない」という状況になりがちです。 テスト対象がより速く実行できるなら、それに越したことはないため、テスト対象によってツールを選ぶと良い、というのが私の考えです。 Shota Tamura2023/05/22お返事いただきありがとうございます！ CI待ちでマージするのに数十分待たなければいけない この視点は抜けていました。これが理由で後々テストを書き直すことになるのは避けたいですね。 一旦、両方を併用しつつ、特に必要がなければJestで書いていく方向でやってみたいと思います🙏 返信を追加
Shota Tamura2023/05/22書籍拝読いたしました。あいまいな知識が線で繋がり、今後に大いに役立ちそうです。ありがとうございます🚀 もし差し支えなければ、一点ご質問させていただいてもよろしいでしょうか🙏 現在、Unit Test と E2E Test の中間にある、Integration Test を充実させるのが一番効果的だよ、という世の流れだと理解してます。 このIntegration Testを書く手法として、本書籍では Jest + React Testing Library を活用されていたと思います。一方で、もしかしてPlaywrightでも、わりと似たようなことができるのではないか？という個人的な感触がありました。 たとえば、アサーションなどはどちらでも同じようなAPIが用意されていそうでした。 特定のテキストを持つ 特定のCSSが適用される URLに特定のQuery Stringをもつ また、アクションもほぼ同等のものがあるかと思います。 クリックする 文字を入力する inputで画像ファイルを選択する 今後、当方は画面単位でのざっくりした統合テストを書いていこうかと思っており、JestでやるかPlaywrightでやるか迷っています。 VRTが簡単にできたり、画面上で視覚的なデバッグができることを考えると、Playwrightを選択したい一方で、例えばフォームで送信されるデータの精緻な検証などには向かないのかなと思ったりもしており、迷っています。 このあたりどう感じておられるか、ご意見伺えますとありがたいです🙇♂️ Takepepe2023/05/22読んでいただきありがとうございます！ 「Integration Test（結合テスト）が何をさすのか？」というのは、文脈によって人それぞれです。拙書では、インタラクションを伴うものは、テストツールを問わず結合テストと称しています。重要なのは「何をテスト対象とするのか？」ということです。 おっしゃるとおり Playwright でも、結合テスト（機能テスト）ができます。このとき判断基準になるのが「Jest + Testing Library でも同じテストを書くことができないか？」という点に着目することです。 Jest + Testing Library の場合、jsdom という仮想ブラウザ上でテストを実行します。jsdom は実行速度が早い反面、完全にブラウザを再現しきれた環境ではありません。そのため「このテスト対象は jsdom では再現不能だから、Playwright で書こう」という判断になります。 書籍第7章で取り上げているテストは概ね、jsdom で実行できる結合テストになります。画面間を跨ぐ機能、例えば「A画面->B画面->C画面、というような流れでしか再現しない機能」をテストする場合は、Playwright で書くことになります。（ただし、こういった機能はまれで、localStorage を使った機能などです） また、Playwright はブラウザを起動するため、実行速度が遅いです。そのため、はじめのうちはあまり気にならないかもしれませんが、テストが充実してくると「CI待ちでマージするのに数十分待たなければいけない」という状況になりがちです。 テスト対象がより速く実行できるなら、それに越したことはないため、テスト対象によってツールを選ぶと良い、というのが私の考えです。 Shota Tamura2023/05/22お返事いただきありがとうございます！ CI待ちでマージするのに数十分待たなければいけない この視点は抜けていました。これが理由で後々テストを書き直すことになるのは避けたいですね。 一旦、両方を併用しつつ、特に必要がなければJestで書いていく方向でやってみたいと思います🙏 返信を追加
Takepepe2023/05/22読んでいただきありがとうございます！ 「Integration Test（結合テスト）が何をさすのか？」というのは、文脈によって人それぞれです。拙書では、インタラクションを伴うものは、テストツールを問わず結合テストと称しています。重要なのは「何をテスト対象とするのか？」ということです。 おっしゃるとおり Playwright でも、結合テスト（機能テスト）ができます。このとき判断基準になるのが「Jest + Testing Library でも同じテストを書くことができないか？」という点に着目することです。 Jest + Testing Library の場合、jsdom という仮想ブラウザ上でテストを実行します。jsdom は実行速度が早い反面、完全にブラウザを再現しきれた環境ではありません。そのため「このテスト対象は jsdom では再現不能だから、Playwright で書こう」という判断になります。 書籍第7章で取り上げているテストは概ね、jsdom で実行できる結合テストになります。画面間を跨ぐ機能、例えば「A画面->B画面->C画面、というような流れでしか再現しない機能」をテストする場合は、Playwright で書くことになります。（ただし、こういった機能はまれで、localStorage を使った機能などです） また、Playwright はブラウザを起動するため、実行速度が遅いです。そのため、はじめのうちはあまり気にならないかもしれませんが、テストが充実してくると「CI待ちでマージするのに数十分待たなければいけない」という状況になりがちです。 テスト対象がより速く実行できるなら、それに越したことはないため、テスト対象によってツールを選ぶと良い、というのが私の考えです。
Shota Tamura2023/05/22お返事いただきありがとうございます！ CI待ちでマージするのに数十分待たなければいけない この視点は抜けていました。これが理由で後々テストを書き直すことになるのは避けたいですね。 一旦、両方を併用しつつ、特に必要がなければJestで書いていく方向でやってみたいと思います🙏
Discussion
書籍拝読いたしました。あいまいな知識が線で繋がり、今後に大いに役立ちそうです。ありがとうございます🚀
もし差し支えなければ、一点ご質問させていただいてもよろしいでしょうか🙏
現在、Unit Test と E2E Test の中間にある、Integration Test を充実させるのが一番効果的だよ、という世の流れだと理解してます。
このIntegration Testを書く手法として、本書籍では Jest + React Testing Library を活用されていたと思います。一方で、もしかしてPlaywrightでも、わりと似たようなことができるのではないか？という個人的な感触がありました。
たとえば、アサーションなどはどちらでも同じようなAPIが用意されていそうでした。
また、アクションもほぼ同等のものがあるかと思います。
今後、当方は画面単位でのざっくりした統合テストを書いていこうかと思っており、JestでやるかPlaywrightでやるか迷っています。
VRTが簡単にできたり、画面上で視覚的なデバッグができることを考えると、Playwrightを選択したい一方で、例えばフォームで送信されるデータの精緻な検証などには向かないのかなと思ったりもしており、迷っています。
このあたりどう感じておられるか、ご意見伺えますとありがたいです🙇♂️
読んでいただきありがとうございます！
「Integration Test（結合テスト）が何をさすのか？」というのは、文脈によって人それぞれです。拙書では、インタラクションを伴うものは、テストツールを問わず結合テストと称しています。重要なのは「何をテスト対象とするのか？」ということです。
おっしゃるとおり Playwright でも、結合テスト（機能テスト）ができます。このとき判断基準になるのが「Jest + Testing Library でも同じテストを書くことができないか？」という点に着目することです。
Jest + Testing Library の場合、jsdom という仮想ブラウザ上でテストを実行します。jsdom は実行速度が早い反面、完全にブラウザを再現しきれた環境ではありません。そのため「このテスト対象は jsdom では再現不能だから、Playwright で書こう」という判断になります。
書籍第7章で取り上げているテストは概ね、jsdom で実行できる結合テストになります。画面間を跨ぐ機能、例えば「A画面->B画面->C画面、というような流れでしか再現しない機能」をテストする場合は、Playwright で書くことになります。（ただし、こういった機能はまれで、localStorage を使った機能などです）
また、Playwright はブラウザを起動するため、実行速度が遅いです。そのため、はじめのうちはあまり気にならないかもしれませんが、テストが充実してくると「CI待ちでマージするのに数十分待たなければいけない」という状況になりがちです。
テスト対象がより速く実行できるなら、それに越したことはないため、テスト対象によってツールを選ぶと良い、というのが私の考えです。
お返事いただきありがとうございます！
この視点は抜けていました。これが理由で後々テストを書き直すことになるのは避けたいですね。
一旦、両方を併用しつつ、特に必要がなければJestで書いていく方向でやってみたいと思います🙏