✨
テストをするということ
今回は会社の勉強会で使ったMarpをそのまま持ってきました！
テストをするということ
~自動化に向けての第一歩~
目次
- テストの種類
- テストの目的
- テストの分量
- テストを支えるアプローチ
- 自動化しやすいテストの特徴
- テストの自動化
1. テストの種類
- 単体テスト
- 結合テスト
- E2Eテスト(受け入れテスト)
- パフォーマンステスト
- セキュリティテスト
- ユーザビリティテスト
- etc......
<!-- テストには非常に豊富な種類がある。
その大部分が繰り返し実施する必要のあるもの。
自動化したほうが効率的である。
自動化出来ないテストももちろん存在する。
-->
2. テストの目的
- 品質の向上
- バグの早期発見
- リファクタリングの安全性確保
- ドキュメントの代替
- etc......
信頼性の高い実行結果に短い時間で到達する状態を保つことで、
開発者に根拠ある自信を与え、
ソフトウェアの成長を持続可能にすること
by 和田卓人
速度と品質はトレードオフではない。
品質が高いほど速度も上がる。
3. テストの分量
3.1 テストピラミッドとアイスクリームコーン(by T.Wada)
3.2 結局どのくらいのカバレッジが良いの?
- 100%を目指すのは難しい。
- なぜなら、100%を目指そうとすると
System.out.println()などの
コードもテストする必要が出てくるから。 - ただし、ビジネスロジックに関しては100%を目指すことが望ましい。
- 全体で60~80%程度を目指すのが現実的だと言われている。
4. テストを支えるアプローチ
1. TDD(テスト駆動開発)
- 言わずと知れたKent Beckの提唱する開発手法。
- テストを先に書くことで、設計を促進する。
- テストが通る状態をキープし続けることで、品質を保つ。
テスト駆動開発(著: Kent Beck,訳:和田卓人)(Amazon)
2. BDD(振る舞い駆動開発)
- テストコード、ではなくテストケースから書き始める。
- テストケースからテストコードに落とし込み、振る舞いを保証する。
- テストケースはビジネス要件を表現するため、
非エンジニアとのコミュニケーションにも有効。 - Gherkinなどの記述方法がある。
3. ATDD(受け入れテスト駆動開発)
- ユーザーストーリーを元にテストケースを書く。
- テストケースを元に開発を進める。
- ユーザーストーリーを満たすことを保証する。
- BDDとの違いは、ユーザーストーリーを元にするか、ビジネス要件を元にするか。
<!--
BDDもATDDも結局はテスト駆動開発の発展型である。
スピーディーかつ品質の高いものをつくるための工夫がなされている。
うちのチームはどうだろうか？ 受け入れテスト駆動開発っぽいが、本当にそうだろうか？
-->
5. 自動化しやすいテストの特徴
設計時点で疎結合・単一責任が実現されていることが重要。
機能と依存が少なければ少ないほどテストし易い。
1. DDD(ドメイン駆動開発)
- Eric Evansの著書「ドメイン駆動設計」に基づく。
- ビジネスロジックを中心に設計する。
- 外部との接点を最小限に抑える。
- 「中核の事業領域」を中心に設計し、「区切られた文脈」によって分離する。
開発者や非エンジニアとのコミュニケーションを円滑にするために
「同じ言葉」を共有する。
(原著ではそれぞれ「ドメイン」「コンテキスト」と「ユビキタス言語」)
2. ヘキサゴナルアーキテクチャ
- オブジェクト指向型の設計アプローチ。
- ドメインロジックを中心に設計する。
- 外側にはUIやDBなどの外部要素を配置する。
3. Container/Presentationalパターン
- Reactのコンポーネント設計パターン。
- Containerでロジックを持ち、PresentationalでUIを持つ。
- Presentationalは疎結合であるため、テストしやすい。
- Containerはロジックを持つため、テストが必要。
ただしPresentationalをモックすることでテストしやすくなる。
4. Custom hooks
- 前述のContainer/PresentationalパターンをReact Hooksで実現したもの。
- Container／Presentationalより更に疎結合になり、モックせずにテストも可能。
フロントエンド開発のためのテスト入門<br>今からでも知っておきたい自動テスト戦略の必須知識(Amazon)
6. テストの自動化
色々なテストツールがあるが、ここでは主要なものを紹介する。
- Jest
- React Testing Library
- JUnit
- Mockito
- Test Containers <- イチオシ！
- Playwright
7. まとめ
- テストは開発の一部であり、品質を保つために必要不可欠なものである。
- 自動化されたテストは開発速度と品質のどちらにも貢献する。
- テストを書く際には、設計時点で疎結合・単一責任が実現されていることが重要。
- テストを書く際には、テスト駆動開発やドメイン駆動開発などの
設計手法を取り入れることが望ましい。
Discussion