単体テストの考え方/使い方の書評｜モックに迷っていたJavaの現場で読んだ

現職のJava開発で、単体テストをどう書けばいいのか迷っていた時期があります。特に悩んでいたのが、モックの使い方でした。そのときに読んだのが、『単体テストの考え方/使い方』です。

結論から言うと、コードの刷新や新しいコードづくりで、これから単体テストをがっつり書く人に合う1冊です。JUnitの書き方ではなく、「何のためのテストか」「どこまでモックにするか」という考え方の本です。

どこが役に立って、読んでから何を変えたのかを書きます。

単体テストの考え方/使い方はどんな本か

書誌情報はマイナビ出版の書籍ページによるものです。中身は4つの部に分かれています。

前半で単体テストの定義と価値を固め、後半でモック・データベース・アンチパターンといった実務の悩みどころに進む作りです。

読んだきっかけ｜Javaの現場で、モックの使い方に迷っていた

役に立ったところ｜定義・目的・モックの種類

いちばん役に立ったのは、次の3つです。目次で言うと、このあたりです。

• 単体テストの定義：第2章「単体テストとは何か？」の「2.1 単体テストの定義」
• コードを壊さないために作る、という目的：第1章「なぜ、単体（unit）テストを行うのか？」、第4章「良い単体テストを構成する4本の柱」
• モックの種類：第5章「モックの利用とテストの壊れやすさ」の「5.1 モックとスタブの違い」、第9章「モックのベスト・プラクティス」

「なんとなくテストを書く」のではなく、あとでコードを変えたときに壊れていないことを確かめるために書く。この目的がはっきりすると、どんなテストを書くべきかを判断しやすくなります。

モックについては、種類ごとに役割が違うと分かったのが役に立ちました。いちばん基本になるのが、スタブとモックの違いです。

第2章では、モックをどこまで使うかで単体テストの考え方が「古典学派」と「ロンドン学派」に分かれる話も出てきます。この2つの違いはロンドン学派と古典学派の違いにまとめています。

読んでから変えたこと｜実装に依存させない・意味のないテストは書かない

読んでから、職場で単体テストを書くときに2つのことを守るようにしました。職場のコードは載せられないので、ここでは考え方が同じになるように書いた短い例で説明します。

単体テストを実装に依存させない

たとえば、テスト対象の中で呼んでいるメソッドまでモックにして、「呼ばれたかどうか」を確かめるテストがあります。こういうテストは、中の作りを少し変えただけで、結果が正しくても落ちます。

// 実装に依存したテスト：中で呼んでいるメソッドを確かめている
@Test
void 会員は1割引きになる() {
    DiscountPolicy policy = mock(DiscountPolicy.class);
    when(policy.rateFor(MEMBER)).thenReturn(10);
    PriceCalculator calculator = new PriceCalculator(policy);

    calculator.priceOf(1000, MEMBER);

    // 「rateForを1回呼んだか」を確かめている。
    // 計算のしかたを変えると、結果が正しくても落ちる
    verify(policy, times(1)).rateFor(MEMBER);
}

実装に依存させないなら、外から見える結果だけを確かめます。

// 実装に依存しないテスト：外から見える結果だけを確かめる
@Test
void 会員は1割引きになる() {
    PriceCalculator calculator = new PriceCalculator(new DiscountPolicy());

    int price = calculator.priceOf(1000, MEMBER);

    // 中の作りを変えても、900円になる限り落ちない
    assertEquals(900, price);
}

モックを使うのは、メール送信や外部APIのように、テスト対象の外へ出ていくやりとりを確かめたいときに絞ります。本の言葉で言うと、第5章の「観察可能な振る舞い」と「実装の詳細」の区別です。Mockitoの書き方そのものはMockitoの使い方にまとめています。

意味のないテストは書かない

もう1つは、守っているものがないテストを書かないことです。たとえば、値を入れて取り出すだけのgetterのテストは、コードを変えても壊れようがないので、書いても安心は増えません。

// 書かないテストの例：守っているものがない
@Test
void 名前を取得できる() {
    Member member = new Member("トム");
    assertEquals("トム", member.getName());
}

大事なのはテストの数ではなく、壊れたら困る振る舞いにテストがあるかです。

合わなかったところ｜特になし

合わなかったところは、特にありませんでした。注意点を挙げるなら、コード例がC#で書かれていることと、416ページと厚いことです。

今のレベル別の読み方

416ページを前から全部読む必要はありません。今の自分に合わせて、読む章を絞ると早いです。

向いている人・向いていない人

• 向いている人：コードの刷新や新しいコードづくりで、単体テストを書く人。これから単体テストをがっつり書いていく人。モックの使い方に迷っている人
• 向いていない人：JUnitやMockitoの書き方（文法）だけを知りたい人。この本はC#の例で考え方を説明する本なので、書き方は別の記事や公式ドキュメントのほうが早いです

JUnitの記事とあわせて読むなら

この本で考え方を固めたら、Javaでの書き方は次の記事で確かめられます。

• JUnit5の使い方入門：テストクラスの作り方から実行まで
• JUnit assertメソッド一覧：結果を確かめるメソッドの使い分け
• Mockitoの使い方：モック・spy・verifyの書き方
• ロンドン学派と古典学派の違い：モックをどこまで使うかの2つの考え方

読んだ本はほかにも、トムの本棚に並べています。

よくある質問

Q. コード例がC#ですが、Javaの人でも役に立ちますか？

役に立ちます。私もJavaの開発で迷っていて読みました。書かれているのはテストの考え方なので、JUnit5とMockitoに置き換えればそのまま使えます。

Q. 2022年の本ですが、内容は古くなっていませんか？

特定のフレームワークの使い方ではなく、単体テストの目的やモックの使いどころといった考え方の本なので、古くなりにくい内容です。ライブラリの細かい書き方は、公式ドキュメントで確かめてください。

Q. 電子版はありますか？

あります。マイナビ出版の書籍ページでは、紙の本と電子版が同じ価格で出ています。