# 2021/03/07 メンター相談 ###### tags: `メンター相談`,`3月` ## 質問1: ○×を半丁に変更する際にStoriesを変更したが、これは課題の意図に沿っているのか [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recjM7ii5SFsagBC1?blocks=hide) - 松原さんの場合はSquareコンポーネントに表示する値は、Squareコンポーネントの責務にしていたため今回の課題内容でも問題なかった - Player1の場合は×、Player2の場合は○など - 課題の書き方が、Squareコンポーネントに○×を記載していることが前提となっていた - 引数で渡している場合、引数を渡している側のStorybookのスナップショットを行わないと気づけない - こうした場合はスナップショットテストには適さないかもしれない --- - Propsの値が正しいことを確認するためには、渡している親コンポーネントのStorybookで確認する必要がある - Gameコンポーネントで ○× から 半丁 に変更してBoardコンポーネントに渡している場合、Storybook側で設定しているBoardのデフォルト引数を ○× に設定してしまっている場合はスナップショットが落ちない --- - CSS-In-JSを使用している場合、クラス名の乱数の差分だけ表示されているので実際にどの値が変更されているのかわかりずらい - jest-styled-componentsなどのプラグインを導入することで、実際にCSSの値がどのように変化したのか検知できる - 実務ではこういうプラグインをよく入れる - https://www.npmjs.com/package/jest-styled-components - https://github.com/styled-components/jest-styled-components ## 質問2: E2Eテストを実装する際にSquareコンポーネントに `data-e2e`を渡す方法が異なっていたが、どちらがいいのか [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recGh9l1WunFJly5m?blocks=hide) - 今回の課題はただのインデックス番号なので、2番目の実装でも問題なし - ただ、1番目の実装もよく見られる --- - cypressの公式では、任意のIDを付与できるようにしておき、後から選択できるような設計になっている（1番目の実装） - https://github.com/cypress-io/cypress/search?q=data-test --- - "square"などをべた書きしていると、コンポーネントの数が肥大化すると管理しずらいのか - 親で定義されている"square"などと被ってしまう可能性あり - 松原さんはベタ書きで今までは困ったことがない。コンポーネント名を利用している。さすがにコンポーネント名までは被らない - 実際のプロジェクトのテストの量としては単体テスト > 結合テスト > E2Eテストなのでそこまで大量にE2Eを書いていないのでかぶったりしていない - Googleのテストに対する考え方（e2eテストは遅いからあんま書きたくない） - https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html ## 質問3: Winnerが表示されている/表示されていないことを確認するテストの書き方でどちらが良いのか [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recexlaxKUj2Cuw8G?blocks=hide) - 今回のユースケースだと1番目のケースがいい - ただし、時と場合による - 例えば、モーダルの要素を確認する場合はモーダル要素を指定する ## 質問4: 順番にマス目をクリックするテストを記述する際の書き方はどちらがいいのか [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recmL4IiARkAd0gX3?blocks=hide) - 冗長的になってしまっても1行1行べた書きするのか、ForEachを使用するのか - アサーションルーレットの原則を考えると、ForEachの場合はどのテストが落ちてしまったのかわかりずらいので1行1行記載する - ただし、Cypressの場合はテストが通らなかった場合は画面でテストが落ちてしまうため、アサーションルーレットのデメリットがあまり影響ない - ただしクリックの意味が分かれている場合（まずは何かのボタンを押してから、そのあとに指定のボタンを押下するような場合）、1行1行書いたほうがいい - Cypressの公式サイトにも記載されている - BeforeEachにまとめて置き、個々のテストの内部ではエイリアスの参照を行うなど - Cypress Best Practices | Sharing Context - https://docs.cypress.io/guides/core-concepts/variables-and-aliases.html#Sharing-Context - t-wadaさんブログ - https://t-wada.hatenablog.jp/entry/design-for-testability#%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88-%E3%82%A2%E3%82%B5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%AB%E3%83%BC%E3%83%AC%E3%83%83%E3%83%88Assertion-Roulette ## 質問5: スナップショットテストの実務への導入例 [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recdar2KS3fhdimp8?blocks=hide) - 開発者の凡ミス防止を目的に導入している - そこまで信頼を置いていない - コンポーネントを変更して差分が検知できた場合、開発者によってはスナップショットファイル自体を更新してしまって、スナップショットファイル自体の信頼性が落ちてしまう - 1度でもスナップショットファイルが汚染されてしまうともはや信頼できない - Storybookの場合は簡易的な設定のみで使用できるため導入している --- - ESLintにはno-large-snapshotというプラグインが存在する - 巨大なスナップショットファイルをとってしまっている場合はルールではじかれる - 小分けする必要がある - https://github.com/jest-community/eslint-plugin-jest/blob/main/docs/rules/no-large-snapshots.md - snapshop-diffというものもある - スナップショットファイルのサイズを小さくするために、差分を検知した部分だけ保存するようにできる - スナップショットファイルの大本だけをとっておき、テストの際には差分を検知した部分だけを保存するような形 --- - （実務の事例）特定のページの特定のフォントを変える必要があった場合 - 新人さんがAtomコンポーネント自体のフォントを変更してしまっていた - ただしスナップショットテストが落ちたので検知できた - スナップショットテストのいいところはAtomを変更した際に、MOLUCULEなどにどのような変更が発生しているのかも検知できる点 ## 質問6: スナップショットテストの課題時に発生した不具合の解消 [質問全文](https://airtable.com/tblA4yYGHwaqDYKwx/viwAUwNVsR9rOkW6u/recna5mWLYbDPpspD?blocks=hide) - Slackの該当スレッドを参照（[こちら](https://prahachallengeseason1.slack.com/archives/C01G28ESQR4/p1615028892051900)） ## 追加質問: EmotionとStyled-Componentsのどちらを使っている？ - 特にこだわりはない - 参加しているプロジェクトによりけり - Next.jsの場合はConfigの変更を加えずに使用できるものがEmotion - Emotionの方がGoogle検索がしづらいかも？ ## 参考 - snapshot testの差分（特にクラス名の違いとか）を、より分かりやすくしてくれるプラグイン - https://github.com/styled-components/jest-styled-components - cypress、aliasを使って事前にクリックしたい要素を取得しておく方法 - https://docs.cypress.io/guides/core-concepts/variables-and-aliases.html - cypressによる公式サンプルアプリと、e2eテストの書き方集 - https://github.com/cypress-io/cypress-realworld-app - snapshotテストを盛大にディスってるツイートと、それに対するケント・ドッドさんの意見 - https://kentcdodds.com/blog/effective-snapshot-testing - googleの各テスト手法に対する考え方（e2eテストは遅いからあんま書きたくない） - https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html