週1ゆるアウトプット

背景 今週、社内のメンバーから以下のリーダブルテストコードの記事を見せてもらった。 かなり自分の中でささったので、Jestの場合どうするかを考えてみた リーダブルテストコード 過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方 概要 上記の参考記事を参考に、Jest(React)の場合、どのようにリーダブルテストコードを書くかを考えてみた。 今回は、UIコンポーネントとカスタムHookそれぞれのテストコードを書いていく。 本題 参考の記事にはリーダブルテストコードを書くには、以下の様に書く必要がある記載している テストコードにおいて、過度なDRYは読みやすさの敵 賢くてロジカルなテストコードより、誰でも(非エンジニアでも)読める愚直なテストコードを 脳内メモリを使わないテストコードはリーダブル 変数をなくし、上から順番に見るだけでテストの意図がわかるようにする 実行可能なAPIドキュメントだと思ってテストコードを書こう(テストコードはプログラムじゃなくてドキュメント) もっとリーダブルにするコツ 実際のユースケースに近いテストデータを使用する 「あああ」「テストテスト」「ユーザー１」みたいなテストデータはNG describe / context / itの説明を丁寧に書く 「it “適切な値を返す”」みたいな具体性のない説明はNG すべての情報が1画面に収まるテストコードが理想 上下スクロールが頻繁に発生したり、他のファイルが見に行かなきゃいけないのはNG DRY禁止はあくまで原則。適宜メリット・デメリットを天秤にかける。 「明確なメリットがあるDRY」や「可読性の損なわない抽象化」まで放棄するのはNG 上記を考慮して、React(Jest)のテストケースを書いていく UIコンポーネントテスト テスト対象コンポーネント inputタグで入力した値firstNameとlastNameが、pタグで表示されるようになっている。 // @ref: https://react.dev/learn/reusing-logic-with-custom-hooks#custom-hooks-let-you-share-stateful-logic-not-state-itself import { useFormInput } from './useFormInput'; export const Form = () => { const firstNameProps = useFormInput(''); const lastNameProps = useFormInput(''); return ( <> <label> First name: <input type='text' name='firstName' {.

背景 現在以下の書籍でフロントのテストを学習しているので、勉強になったDOMの取得方法をまとめる。 書籍通り、ReactのUIコンポーネントのテスト方法を記載していく。 概要 ReactのUIコンポーネントのDOMを取得する方法で、暗黙的なロールを活用した取得方法があったので、まとめていく 本題 以下のコンポーネントのテストをしていく。 import {ReactNode} from "react"; export const Heading = ({children}: {children: ReactNode}) => { return ( <h1>{children}</h1> ); }; 今回は簡易的に、propsの値がh1タグで表示されているかをテストしていく。 import {render, screen} from "@testing-library/react"; import {Heading} from "./Heading"; test('propsが値がh1タグに存在していること', () => { render(<Heading>test</Heading>) expect(screen.getByRole('heading', {name: 'test'})).toBeInTheDocument() }) 上記のgetByRoleの第一引数にheadingを指定しているが、h1タグの暗黙的なロールがheadingであるため、headingを指定している。 このように暗黙的なロールをうまく使えば、test-idみたいなカスタム属性をなどを使用せずに、テストをかくことができる。 また、Testing Libraryも公式も暗黙的なロールを使用することを推奨している。 暗黙的なルール一覧はこちらから確認ができる。 ※上記はaria-queryというライブラリのドキュメントであるが、Testing Libraryのライブラリは内部的に依存するので、上記を参考にしても問題ない まとめ UIコンポーネントのテストをする際は、暗黙的なロールを使用することで、テストを書きやすくなるので、ぜひ活用していきたい。 参考文献 Testing Library 暗黙的なルール一覧(aria-query) フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識

背景 現在の参画している案件で「週1ゆるアウトプット」という名前でアウトプットしている方がいたので、自分も真似してみようと思う。 今回は、コードを書いていてふと気になったことがあったので、簡単にまとめていく。 概要 戻り地がある関数を命名するときに、createXXXとgetXXXのどちらを使うか迷ったので、まとめていく。 本題 以下はサンプルコードを記載する。 名前のフルネームを作成する関数である。 createFullNameとgetFullNameのどちらが適切かをまとめていく。 // 1. createXXX const createFullName = (firstName: string, lastName: string): string => { return `${firstName}${lastName}` } // 2. getXXX const getFullName = (firstName: string, lastName: string): string => { return `${firstName}${lastName}` } ポイントとしては、getXXXは通常、既存のデータやリソースを取得するときに使用することを想定すること。 createXXXは新しいデータを作成するときに使用する。 なので、今回の場合は、既存のデータやリソースを取得するわけではないので、createXXXを使用するのが適切だと判断。 getXXXを使ったサンプルは以下 ユーザー情報を取得する場合 const getUserInfo = (userId: string) => { // ユーザー情報を取得するロジック }; 配列から特定の要素を取得する場合 const getElementAtIndex = (array: string[], index: number) => { return array[index]; }; オブジェクトのプロパティ値を取得する関数 const getPropertyValue = (object: Object, propertyName: string) => { return object[propertyName]; }; まとめ 今回は、関数の命名についてcreateXXXとgetXXXのどちらを使うか迷ったので、まとめてみた。 getXXXは通常、既存のデータやリソースを取得するときに使用することを想定すること。