React Testing LibraryのDocsを読む
hajimism今まで雰囲気でやってきたため、ドキュメントをちゃんと読む
hajimismAs 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のブログにも書いてあったな
hajimismrenderにhydrateオプションあったんや
hajimism
hajimismHow 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')
})
ドキュメント内で何度も参照されている
hajimismまあでもやっぱりこの一言に尽きる
The more your tests resemble the way your software is used, the more confidence they can give you.
hajimism
hajimismわかりやすすぎます
hajimism
クエリの優先順位は
- Queries Accessible to Everyone Queries that reflect the experience of visual/mouse users as well as those that use assistive technology.
- Semantic Queries HTML5 and ARIA compliant selectors. Note that the user experience of interacting with these attributes varies greatly across browsers and assistive technology.
- Test IDs
っていう大枠があって、さらに各項目で細分化されている。getByRoleとname指定で大体事足りるんじゃ？とのこと
hajimism拡張機能もあるんや
hajimismなるほどめちゃ便利やな。教育に良い。
hajimismgetByRoleだけ詳しく見ときますか
hajimism
hajimismえ、知らんかった
// 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イベントって無い？
hajimismJSDOMはレイアウトの概念を持たないのでE2Eでカバーする範囲だと。
hajimism↑で気になったのでテストの使い分けに関してのブログを読む
hajimism下記の図のトレードオフを前提に、「happy pathはE2E」みたいな感じで使い分けよー、みたいな
hajimismテスト設計上手い人は問題の切り分けについて慎重に検討しているイメージ
hajimismE2E落ちちゃってるけど、Unitテストでここまで保証できているから、ここらへんが怪しいはずで、じゃあここだけピックアップしてIntegrationテスト書いてみよかー、みたいな
hajimismあとはなんでもかんでもテスト書きゃいいってわけじゃなくて（メンテコストとのトレードオフ）、「なんかの拍子に壊れそう」「影響範囲でかそう」「モジュールとして頑健で、そのままのかたちで生き残りそう」みたいなところを選んで書いているイメージ。経験則なのかな？