React のテストと Implementation Details

Implementation Details とは

ひさしぶりに React を書いていてテストを書きたくなった。現在は Testing Library の使用が推奨されているらしい

testing-library.com

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 をテストするテストはなぜイケてないかは以下のブログ記事が詳しい

kentcdodds.com

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 をみると、このあたりの思想がよく現れている。

testing-library.com

開発者としてはついつい document.getElementByIddocument.querySelector が使いたくなるが、 Testing Library ではテキストの中身や Role を指定して UI コンポーネントを絞る必要がある

Tauri の本を書いた

OwnServer という趣味プロジェクトを作っています

ownserver.kumassy.com

このプロジェクトではデスクトップアプリを作る必要があったので、いろいろと調べて Tauri という GUI フレームワークを使うことにしました

tauri.studio

Tauri について知見が溜まったので、 Zenn に入門書を書いてみました

zenn.dev

Zenn は本を書くと収益化できるので、全部無料公開にしてチップを受け付けるかたちにしてみました。 700 円あれば近所のラーメン屋さんでラーメンを食べることができます。 よろしくお願いします

ドメインを移管した

ドメイン kumassy.com を Google Domains に移管しました。

kumassy.com は 2015/01/27 にムームードメインで購入したようです。

muumuu-domain.com

2015/01 頃はまだ高校生で受験生のはずです。センター試験が終わって一段落ついたところで、景気づけにドメインでも買ったのでしょう。当時はクレジットカードをもっていなかったので、近くのコンビニに行って Webmoney を買って購入した記憶があります。

さてそんなムームードメインですが、 付属の DNS サーバーに NS レコードを登録できないという問題がありました。

DNSレコードを設定することはできますか

https://support.muumuu-domain.com/hc/ja/articles/360045802434-DNS%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AF%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%99%E3%81%8B

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 に移管できました。