テストコードの名前の付け方

単体テストとは、1単位の振る舞いについての1つの不可分な事実 (シナリオ) を伝えるもの

だから、事実を伝えるための命名にする必要がある。

p77

避けるべき理由は、実証の詳細について書いているから。

テストは振る舞いを検証するものだから、テストの名前も振る舞いに関して命名するべき。

目指すべき名前は、「テスト対象の振る舞いをそのまま表現したもの」

これ、書きがちだから気を付けたいね...

p79

テスト・メソッドに名前を付けるときの指針

厳格な命名規則を決めないで、自由に記述できるようにする → それによって、いろんな表現ができるようになり、読みやすく理解しやすくなる。

非開発者 (ドメインエキスパートなど) にも意味が通じるような命名にする → 開発者にとっても、どのような検証をしているのかがより理解しやすくなる。

(英語の場合は) アンダースコアを使って絵単語を区切るようにする

p80

単体テストは、1つの振る舞いを検証する。

だから、1つのクラスに対して1つのテストクラスというわけではない。

1つの振る舞いに複数のクラスがまたがることもある。

p81

なぜ、テスト対象のメソッド名をテスト・メソッド名に含めるべきではないのか？

その理由は、単体テストはコードをテストしているのではなく、アプリケーションの振る舞いをテストしているからです。そのため、テスト対象のメソッド名がなんであるかはテストには関係のないことになります。

...

テスト対象のメソッド名を別の名前に変えた場合、振る舞い自体は変わらないため、テスト・ケースに対して影響を与えてはなりません。しかしながら、もし、メソッド名を含める命名規則を採用していた場合、テスト・メソッド名も修正しなくてはならなくなります。つまり、振る舞いではなくコードがテストと結びついていることになるのです。

例外もある。

その例外とはユーティリティ系のコードをテストする場合です。なぜなら、ユーティリティ系のコードにはビジネス・ロジックは含まれておらず、その振る舞いは単純な補助的機能でしかないため、ビジネス的に関係するものではないからです。

util とか helper 系のものは、テスト名に含めてOK。

p82

しかしながら、テスト・メソッド名に「should be (べきである)」とつけることはよくあるアンチ・パターンの一つです。この章の最初の方で、単体テストとは、1単位の振る舞いについての1つの不可分な事実 (シナリオ) を伝えるものである、ということを述べました。そして、事実について伝えるのであれば、そこに希望や要望を含めるべきではありません。そのため、テスト・ケースには事実に基づいた名前を付けるべきであり、「べきである (should be)」を「である (is)」に変えなくてはなりません。

過去の日付が指定された配達は不正とすべきである

→ 過去の日付が指定された配達は不正である