https://appkitbox.com/testkit/knowledge/test/20121112-105
https://teratail.com/questions/127312
- 全publicメソッドについて、正常系異常系ともに全てテストを書くことでユニットテストの効果が最大限に発揮される
- 静的テスト
- ソースコードをレビューし、設計仕様書と矛盾はないか、バグは無いかなどをチェック
- 静的解析ツールを使用して、コーディング規約の違反はないか、リスクやバグはないか、メトリクスは妥当か、といった診断を行う
- 動的テスト
- ユニットテスティングフレームワークを使用して、テスト対象であるユニットを動かし、その動作結果を検証する
- ユニットテストの目的
- リファクタリングにおいて、挙動が変化していないか、バグが混入していないかチェックする回帰テスト
- ソースコードにバグが混入しないか継続的に監視する監視役として活用
- 設計の検討・改善の支援や、プログラミングの進捗確認の手段として活用
- ソースコードのふるまいを説明するドキュメントとして扱う
- ユニットテストの効果と課題
- メリットを活かすためには、ユニットテストをいつ、どのような目的で、どのような段取りで活用するかという、テスト戦略を工夫する必要がある
- メリット
- 全体が完成していなくても、テスト対象のユニットさえ確保できればテストが実施可能
- 開発環境上でテストを実施することができ、実行環境の制約を緩和できる
- UIといった外部のインターフェースから分離して動的テストを実行できるため、結合テスト、システムテストと比べ動的テストの自動化が容易
- 通常操作では再現の難しい、特殊な例外処理や組み合わせもテストできる
- デメリット
- 実装や管理にはプログラミングスキルが要求される
- 保守性を確保するためには、綺麗な設計やスタイルが求められるほか、バージョン管理といった適切な構成管理も要求される
- ユーザインターフェースや機能といったシステムレベルのテスト対象を検証するのが困難
- ユニットテストを網羅的に実施したといっても、システムとしてバグがないと保障できない
- 動的テストの場合、テスト対象のインターフェースとテストが強く結合する
- 動的テストの場合、テスト対象が依存するコンポーネントを切り離すために、テストダブル（テストスタブやモック、フェイクオブジェクト等の総称）を組み込む手間が発生する場合あある
- テスト対象に高いテスタビリティを要求します。複雑に結合したユニットに対してユニットテストを作成するのはかなり困難
- ユニットテストの設計
- ホワイトボックスのテスト設計技法、ブラックボックスのテスト設計技法両方を活用
- ユニットテストの網羅性：ユニットテストがテスト対象のソースコードをどの程度網羅しているかの指標
- テスト漏れの検出等で有効に使用できる
- コードカバレッジ100%といっても、コードの欠落や仕様との矛盾は検出できない
- 高水準のコードカバレッジの実現は、非効率な作業となりがち