はじめに
最近、ふと一人でまるまるSNSを作った時の事を思い出しました。
作成にはいいねやDMのログ管理やセキュリティの実装含め、シンプルな構成でテスト無しでも1ヶ月。
あの状態でなぜメンタルが壊れなかったか？
それは“これには大体これ位の時間がかかる”といった先が見えていたのが何よりだったのかもしれません。
お盆前ですし不安なく今年度の前半戦を振り返って、タスクをまとめたい人も多いかと思います。
また、春から始まっているプロジェクトは、秋にテストを迎えるチームも多くあるかと思います。
それにちなんでReactのテスト工程に向けた各種ドキュメントやステップを今回は付録にしようと思います(若干アジャイル癖があるため、ガバガバですがその分実践向けです。)📖🖋
皆さんも聞き覚えがあるでしょうバーチャート等からホッと一息、復習してみましょう。
システム開発において大規模な機能やドメインを管理する際、心理的負担を軽減するためのプロジェクト管理書類：
-
作業分解構造図（WBS）: 大きな作業を小さく管理可能な単位に分割し、全体像と進捗を視覚化します
-
マイルストーン計画: 長期間の開発を複数の達成可能な中間目標に分け、小さな成功体験を積み重ねられるようにします
-
リスク登録簿: 予想される障害を事前に特定し、対応策を計画することで不安を軽減します
-
簡潔な進捗レポート: シンプルなダッシュボードや信号機方式（赤・黄・緑）で状況を一目で把握できるようにします
-
バーンダウンチャート: 残作業の視覚化により、進捗を実感しやすくします
-
タスクカンバン: 作業の流れを視覚化し、WIP（進行中作業）を制限して過負荷を防ぎます
-
定期的な振り返り記録: 短いサイクルでの成功や改善点を記録し、モチベーションを維持します
これらの文書は、大規模な作業を管理可能なサイズに分割し、進捗を視覚化することで、チームの心理的安全性を高め、負担感を減らすのに役立ちます。
複雑な React コンポーネントのユニットテスト WBS 例
※あくまで投下目安日数よりも、遥かに参考になるのは各フェーズの日数の「比率 」です。
たとえばコード分析に2日かかるなら、この記事の2倍のスケールのプロジェクトなわけですから、他の作業時間も倍かかると計算してください。
そうすれば、自分の取り組まれているものに一体何日かかるか想像できるようになります。
お盆くらい安心して帰れるようにとの願いを込めての投稿です。
この記事を見ているエンジニアの皆さん、共にこの灼熱の夏を乗り切りましょう🍧☀️
レベル 1: 複雑な React コンポーネントのユニットテスト作成
レベル 2: テスト環境の理解と準備 (期間: 4日)
この図は以下の内容を視覚化しています：
- テスト対象のコンポーネント（ProductList）とその依存関係
- 必要なモックとその階層構造
- 各テストケースが依存するモック
- モック間の依存関係
このような図を作成することで、どのモックがどのテストケースに影響するかが明確になり、モックの変更がテストに与える影響範囲を把握しやすくなります。テストの開発中に特定のモックを修正した場合、どのテストケースを再確認する必要があるかも一目瞭然です。
レベル 3: 対象コンポーネントのコード分析 (1日) の成果物例
1. コンポーネント構造と依存関係の図式化
2. データフローの理解
データフロー図
データ状態マッピング
| データソース | データ項目 | 使用コンポーネント | 読取/書込 | 更新トリガー |
|---|---|---|---|---|
| Redux | products[] | ProductList | 読取 | ページロード, フィルター変更 |
| Redux | currentFilters | FilterPanel | 読取/書込 | ユーザー入力 |
| Redux | pagination | Pagination | 読取/書込 | ページ切替ボタンクリック |
| Redux | cart[] | AddToCartButton | 書込 | ボタンクリック |
| LocalStorage | favorites[] | FavoriteButton | 読取/書込 | ボタンクリック |
| UserContext | preferences | ProductCard | 読取 | - |
3. 条件分岐と副作用のマッピング
条件分岐マップ
副作用マップ
| コンポーネント | 副作用種類 | トリガー | 依存配列 | 影響範囲 |
|---|---|---|---|---|
| ProductDashboard | useEffect | コンポーネントマウント | [] | ProductAPIからデータ取得 |
| ProductDashboard | useEffect | フィルター変更 | [filters] | ProductAPIからデータ再取得 |
| ProductDashboard | useEffect | ページ変更 | [currentPage] | ProductAPIからデータ再取得 |
| AddToCartButton | useCallback | ボタンクリック | [dispatch, productId] | ReduxのCartStateを更新 |
| FavoriteButton | useCallback | ボタンクリック | [productId, isFavorite] | LocalStorageを更新 |
| ProductList | useMemo | products変更 | [products, sortOrder] | 表示用にソートされた商品リスト生成 |
テスト難易度評価
| コンポーネント | 条件分岐複雑度 | 副作用複雑度 | データ依存度 | 総合テスト難易度 |
|---|---|---|---|---|
| ProductDashboard | 高 | 高 | 高 | 高 |
| ProductList | 中 | 低 | 高 | 中 |
| ProductCard | 中 | 中 | 中 | 中 |
| FilterPanel | 低 | 中 | 中 | 低 |
| AddToCartButton | 低 | 高 | 低 | 中 |
| FavoriteButton | 中 | 高 | 中 | 高 |
このような成果物を作成することで、テスト実装前にコンポーネントの複雑さを理解し、必要なモックを計画的に準備できます。また、条件分岐のマッピングによりテストケースを漏れなく網羅することができます。
-
レベル 3: テストツールセットアップ (2日)
- Jest/React Testing Library の設定確認
- 必要なテストヘルパーの特定
- テスト環境の問題特定と修正
-
レベル 3: テスト戦略の策定 (1日)
- テスト優先順位の決定
- モック方針の文書化
- テスト分割案の作成
レベル 2: データストア依存関係のモック作成 (期間: 10日)
-
レベル 3: データストア依存関係の特定 (2日)
- 直接的データストア呼び出しのリスト化
- 間接的データストア依存のトレース
- 副作用を持つ操作の特定
-
レベル 3: モックオブジェクトの設計 (3日)
- Redux ストアのモック設計
- Context API 利用部分のモック設計
- API 呼び出しのモック設計
-
レベル 3: モック実装 (3日)
- 基本的なモック実装
- エッジケース対応のモック実装
- 非同期操作のモック実装
-
レベル 3: モック検証 (2日)
- 個別モックのユニットテスト
- モック組み合わせテスト
- モックの再利用性確保
レベル 2: コンポーネントテストの段階的実装 (期間: 12日)
-
レベル 3: レンダリングテスト (3日)
- 基本レンダリングテスト
- 条件付きレンダリングテスト
- エラー状態レンダリングテスト
-
レベル 3: イベントハンドラテスト (4日)
- ユーザー入力イベントテスト
- フォーム送信テスト
- カスタムイベントテスト
-
レベル 3: 副作用テスト (5日)
- useEffect 呼び出しテスト
- 状態更新テスト
- コールバック連鎖テスト
レベル 2: テスト統合と最適化 (期間: 4日)
-
レベル 3: 個別テストケース統合 (2日)
- テストケース間の依存関係解消
- テスト実行順序の最適化
- 共通テスト前提条件の抽出
-
レベル 3: テストパフォーマンス改善 (2日)
- テスト実行時間の分析
- モックの最適化
- テストの並列実行設定
進捗管理ツール
- マイクロタスク進捗表: 1日単位の小タスクに分割し、毎日クリアできる達成感を得られるようにする
- モック依存関係図: どのモックがどのテストに影響するかを視覚化
- デイリーブロッカー記録: 毎日のブロッカーを記録して早期解決を促進
- テストカバレッジ増分チャート: 日々のカバレッジ向上を可視化して進捗を実感
これにより、「1ヶ月かかる大きなタスク」という漠然とした不安を、日単位で達成可能な具体的な作業に分解し、進捗を可視化することで心理的負担を軽減できます。