React Testing LibraryのDocsを読む

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.

The more your tests resemble the way your software is used, the more confidence they can give you.

The utilities this library provides facilitate querying the DOM in the same way the user would. Finding form elements by their label text (just like a user would), finding links and buttons from their text (like a user would).

ここらへんはKentのブログにも書いてあったな

rerender
使ったこと無い気がする
https://testing-library.com/docs/react-testing-library/api#rerender

snapshot testをするのに便利なasFragment
https://testing-library.com/docs/react-testing-library/api#asfragment

How do I test input onChange handlers?

ほんとに頻出パターンだ

test('change values via the fireEvent.change method', () => {
  const handleChange = jest.fn()
  const {container} = render(<input type="text" onChange={handleChange} />)
  const input = container.firstChild
  fireEvent.change(input, {target: {value: 'a'}})
  expect(handleChange).toHaveBeenCalledTimes(1)
  expect(input.value).toBe('a')
})

まあでもやっぱりこの一言に尽きる

The more your tests resemble the way your software is used, the more confidence they can give you.

わかりやすすぎます

https://testing-library.com/docs/queries/about/#priority

クエリの優先順位は

1. Queries Accessible to Everyone Queries that reflect the experience of visual/mouse users as well as those that use assistive technology.
2. Semantic Queries HTML5 and ARIA compliant selectors. Note that the user experience of interacting with these attributes varies greatly across browsers and assistive technology.
3. Test IDs

っていう大枠があって、さらに各項目で細分化されている。getByRoleとname指定で大体事足りるんじゃ？とのこと

拡張機能もあるんや
https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano

なるほどめちゃ便利やな。教育に良い。
https://testing-playground.com/

第二引数の各プロパティは各ARIA属性に対応している感じか

heading levelやspinbutton valueも指定できる

え、知らんかった

// Note: The 'value' attribute must use ISO 8601 format when firing a
// change event on an input of type "date". Otherwise the element will not
// reflect the changed value.

// Invalid:
fireEvent.change(input, {target: {value: '24/05/2020'}})

// Valid:
fireEvent.change(input, {target: {value: '2020-05-24'}})

scrollイベントって無い？

JSDOMはレイアウトの概念を持たないのでE2Eでカバーする範囲だと。
https://github.com/testing-library/react-testing-library/issues/671

下記の図のトレードオフを前提に、「happy pathはE2E」みたいな感じで使い分けよー、みたいな

テスト設計上手い人は問題の切り分けについて慎重に検討しているイメージ

E2E落ちちゃってるけど、Unitテストでここまで保証できているから、ここらへんが怪しいはずで、じゃあここだけピックアップしてIntegrationテスト書いてみよかー、みたいな

あとはなんでもかんでもテスト書きゃいいってわけじゃなくて（メンテコストとのトレードオフ）、「なんかの拍子に壊れそう」「影響範囲でかそう」「モジュールとして頑健で、そのままのかたちで生き残りそう」みたいなところを選んで書いているイメージ。経験則なのかな？