単体テストの考え方・使い方を読んでる（後編）drc#51

デッドライン読書会50回と今回51回の課題図書は「単体テストの考え方・使い方」です。51回では7章から最後まで読んでいきます。読み切れていないけど（ただ最後まで目は通してる）、感想を書きます！

後半部分の感想

後半は7章から11章までで下記のような章立てです。

第2部: 単体テストとその価値
- 第7章: 単体テストの価値を高めるリファクタリング
第3部: 統合（integration）テスト
- 第8章: なぜ、統合（integration）テストを行うのか？
- 第9章: モックのベスト・プラクティス
- 第10章: データベースに対するテスト

以上の章を読んで気になったところをピックアップします。

リファクタリング（7章）を検討するに当たってプロダクション・コードを4種類に分類するという説明が良い。2軸4種類と数が少ないこともあり実務的にも使いやすそうです。

統合テスト（Integration Test）は、本書の定義では「単体テストではないテスト」のことを指す。テスト対象のシステムがプロセス外の依存と結合した状態でどのように機能するかを検証する位置づけとなる。

そういえばエンタープライズSI的な領域だと実際の言葉の使われ方が違うことも多い。例えば以下のような分類。

私は下記のように分類して開発することが多いかなぁ。（JSTQB的な標準にもう一度立ち戻らなくちゃいけない気がしてきた…）

単体テスト　をさらに分類
- モジュール単体テスト
  - xUnitを利用したもの。本書の単体テストと本書の統合テストが含まれる。
- 機能単体テスト
  - 1つの機能に対するテスト。いわゆる「打鍵」をして画面のアクションを稼働させるテスト。
内部結合テスト（ITa）
- 業務フローをもとにシステム内に閉じた機能検証、品質保証活動。
外部結合テスト（ITb）
- 外部システムを接続して関連システム全体の連動を確認する機能検証、品質保証活動。