React のテストと Implementation Details
Implementation Details とは
ひさしぶりに React を書いていてテストを書きたくなった。現在は Testing Library の使用が推奨されているらしい
Testing Library の Doc をみると、
You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended.
https://testing-library.com/docs/react-testing-library/intro
とある。 React コンポーネントをテストするときは Implementation Details をテストしないようなテストを書くといいとのこと。
Implementation Details とはなにか、 Implementation Details をテストするテストはなぜイケてないかは以下のブログ記事が詳しい
Implementation Details とは、例えば State のプロパティ名や onClick
にわたす関数名などがある。 React Component のリファクタをするときに、これらのプロパティ名や関数名は変わるときがある。しかし、 enzyme
というテストフレームワークでは実装の詳細についてテストする書きっぷりになっているので、リファクタリングするたびにテストが壊れてつらいらしい。例えば、 enzyme
のテストコードでは、 State を変更するために
const wrapper = mount(<Accordion items={[]} />) expect(wrapper.state('openIndex')).toBe(0)
のように直接 state
を変更する必要がある。仮に openIndex
というプロパティ名を変えようとすると、テストコードの修正もつらい。
Testing Library では、 直接 State を変更するのではなく、ユーザーの操作をシミュレートすることで State を変更する。例えば openIndex
を操作するためにはユーザーはボタンをクリックするはず。 Testing Library では
render(<Accordion items={} />) userEvent.click(screen.getByText("next"))
のようにしてユーザー目線で操作する。こうすることで、 State の内部設計 Implementation Details に踏み込むことなくテストコードを記述できる
React 特有の事情
React のテストコードで Implementation Details に特に注意しなければならない理由に、 React 特有の事情がありそうだ。 React Component のユーザーは、開発者とエンドユーザーがいる。
例えば Rust でなにかライブラリを作ることを考える。このライブラリの利用者は開発者である。公開する struct や 関数名を制限することで、あとからリファクタリングがしやすくなる。この公開インターフェイスに関してテストコードが書かれていると安心できるだろう。
React Component のユーザーは開発者とエンドユーザーである。 開発者にとっての公開インターフェイス props の名前やコールバック関数名になる。 一方で、エンドユーザーにとっては、ドロップダウンメニューのテキストやボタンがインターフェイスとなる。 React は最終的にはエンドユーザーにむけてサービス提供するので、テストもユーザーと同じ目線になって記述すべしということだ。
Testing Library の Query をみると、このあたりの思想がよく現れている。
開発者としてはついつい document.getElementById
や document.querySelector
が使いたくなるが、 Testing Library ではテキストの中身や Role を指定して UI コンポーネントを絞る必要がある
Tauri の本を書いた
ドメインを移管した
ドメイン kumassy.com を Google Domains に移管しました。
kumassy.com は 2015/01/27 にムームードメインで購入したようです。
2015/01 頃はまだ高校生で受験生のはずです。センター試験が終わって一段落ついたところで、景気づけにドメインでも買ったのでしょう。当時はクレジットカードをもっていなかったので、近くのコンビニに行って Webmoney を買って購入した記憶があります。
さてそんなムームードメインですが、 付属の DNS サーバーに NS レコードを登録できないという問題がありました。
DNSレコードを設定することはできますか
kumassy.com のサブドメインを Route53 などで管理したかったので、これでは困ります。ということで、 Google Domains に移管することにしました。
ムームードメインの購入履歴がこれです こうしてみると年々知らないうちに値上げしていたのですね。気づいたら Google Domains より高くなっていました。
移管手順は簡単で、このあたりの手順に沿えば OK です。
ドメインを他社へ移管したい(『.jp』以外) https://support.muumuu-domain.com/hc/ja/articles/360046369393-%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%82%92%E4%BB%96%E7%A4%BE%E3%81%B8%E7%A7%BB%E7%AE%A1%E3%81%97%E3%81%9F%E3%81%84-jp-%E4%BB%A5%E5%A4%96-
ムームードメイン側で Auth Code を発行し、 Google Domains 側で移管申請をしました。
ところが、 3 日ほどだってもムームードメインから 【重要】トランスファー申請に関する確認のご連絡
というメールが来ていないことに気づきました。これはおかしいと思って Gmail を漁ったところ、 Google Domains 側での移管申請のあと 1 時間もしないうちにメールが来ていました。
ムームードメインからの DM が鬱陶しくて @muumuu-domain.com
からのメールをアーカイブする設定にしていたのが原因でした...。
その後は順調に手続きが進み、 Google Domains に移管できました。