UIのテストについての神話

これは、Kent C. Dodds 氏のブログ記事であるUI Testing Mythsを日本語訳してみたものです。

誤訳などあればIssueや PR を頂けると幸いです。

---

神話 1: ”コードに変更を加えるといつもテストが壊れる”

実際のところこれは本当です。。誤ったテストが書かれていれば。もし実装詳細をテストしていれば、当然実装が変更された時にテストが壊れます！ですがユーザーは実装詳細に関心がありません。実際、ユーザーは React でも Angular でも jQuery でも何が使われているかを気にしません。なので、ほとんどの場合、テストについてもそのことを気にする必要がありません。💯

残念なことに、多くのツールは実装詳細のテストを推奨しています。それに従うと、テストを書き直すことが多くなる傾向にあります。”なぜこのようなものまでテストしているのか？”と自問するかもしれませんが、それも仕方のないことです。それがTestingJavaScript.comにおいて私が正しいテストのやり方を伝えている理由です。

神話 2: ”redux に’繋いだ’コンポーネントをテストできない”

Redux を使っているコンポーネントのテストの従来の常識は、コンポーネントを Redux から分離してテストして、Redux の action creator や reducer を分けてテストするというものでした。

ですが、このようにすると、テストはコンポーネントが Reduxと適切に連携できているかどうかについての信頼を全く与えてくれません。

代わりに、本当の Redux store と繋いだコンポーネントを実際にテストすることができます。そうすると、コンポーネントが適切にレンダリングされることとRedux の action creator や reducer が全て一緒に連動して機能していることに信頼を与えてくれます。本番と同じように。 ✅

TestingJavaScript.comにおいて、私はこのようなテストの方法について紹介しています。React Router🔀 や他のプロバイダー（emotion 👩‍🎤 の Theme Provider など）にも同じ考え方を適用できて、このコースではどのようにしてそれらを適用するのかも紹介しています！

神話 3: ”E2E テストは遅くて脆い”

これも誤ったテストが書かれている場合に本当のことになります。私が E2E テストにおいてよく目にする間違いは、テスト毎に同じことをしているというものです—例えば、全てのテストがテストで必要なことの前に、登録とログインの全フローを行うということです。こういうことをすると、多くの重複を目にすることになり、”page objects”（悪いプラクティスです）のようなものを作り始めるわけです。 😐

TestingJavaScript.comにおいて、私は登録とログインのフローが機能していることに自信が持てる方法を紹介していて、残りのテストではそれらをスキップすることで格段に速くして、障害点を減らすようにしています。Cypress Testing Libraryのようなツールを利用してこのような形でテストをすると、page objects のようなプラクティスは全く必要のないものとなり、テストのメンテナンスが容易になり、信頼できて、より高速に実行できるようになります。開発のワークフローツールとして Chrome を Cypress へと置き換えることさえありえるかもしれません（その方法もまたコースで紹介しています！）😱