[テスト駆動開発(TDD)] 第21章 要約

概要

TDD本（※）の第21章を読んで要約したのでメモしておきます。
TDD本を読んで「ここで言ってることはどういうこと？？」となっている方の参考になれば幸いです。
※https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

第21章 要約

残りTODO

• [] テストメソッドが失敗したとしてもtearDownを呼び出す
• [] 複数のテストを走らせる
• [] 収集したテスト結果を出力する ◀︎ NEXT

次にやりたいこと

テストメソッドが失敗してもtearDownが呼ばれるようにしたい。
しかし、失敗したときに落ちずにtearDownが呼ばれるようにすると、落ちないので失敗した場所がわからない。
なので、失敗した場所の例外をキャッチする必要がある。

テストを書く順番は重要で、筆者は次に書くテストを選ぶときは「何らかの気づきがある」か「動いたときに自信をもたらしてくれる」ものを選ぶ。
→「書こうとしているテストに少しでも不安があるときは、テストの対象を細分化して（TDD本的に言うと小さいステップに切り分けて）、目的や次のステップが明確なテストを先に書いて動かすべき」ということが言いたいのでは、と捉えたのですが、正直まだよく理解できていません。。読み進める中で理解できたら更新します。

テストが動くようになっても、その次のテストを書く手が止まってしまうようであれば、2歩戻ろう。

（２歩前） テストを考えて、書く（1つ前に書いたテスト）
↑（1歩前） テストが動く（1つ前に書いたテスト）
↑（現在） 次のテストを考えて、書く　→テストを書く手が止まっている

2歩前の「1つ前に書いたテストを考える」ステップまで戻って考え直そう、ということだと思う。

TesyResult（テスト結果）のテストを追加する

まずは、「テストの実行数、失敗数、失敗の内容」という感じでテストツールっぽい実行結果を出したい。
ただ、いきなりフレームワーク自動的に全てのテスト結果（どのメソッドがどんな理由で落ちたかなど）をレポートさせるのは難しい（ステップが大きすぎる）。

一歩目として、1つのテストを走らせたときに結果を記録したTestResultを返すようにするのがいいのでは？
これだと一つの結果しか扱えないが、まずはこれくらいの小さいステップで着手することが大事。

[ソース更新]
TesyResultのテストメソッド、テスト実行コードを追加。

仮実装

次に仮実装。

[ソース更新]
TestResultクラスを追加し、結果内容を返すsummaryメソッドを作成（仮実装なので返り値はベタがきの文字列）。
runメソッドがTestResult（テスト結果）を返すように更新。

仮実装を本物に近づける①

テストが通ったので、仮実装してたTestResultクラスのsummaryメソッドを本物に近づける。

[ソース更新]
TestResultのコンストラクタでrunCount（テスト実行数）に１を代入するようにする。（まず小さいステップで進める。）
ベタがき文字列だった返り値の「テスト実行数」の表示部分にrunCountが表示されるようにする。

ひとまず定数になっているrunCountは、本来、テスト実行ごとに増えるべきなので修正する。

[ソース更新]
runCountの初期値を０とし、テスト実行ごとにインクリメントするためのtestStartedメソッドを追加。

runメソッドの中で作りたてのtestStartedメソッドを呼ぶ。

[ソース更新]
runメソッドの中で生成したTestResultインスタンスに対してtestStartedメソッドを実行し、runCountをインクリメントする。

仮実装を本物に近づける②

もう1つのベタがき数字（失敗数のほう）を本物にしたい。
テストを書こう。

[ソース更新]
テスト失敗時のテスト（testFailedResult）を追加。
↑でテストされるテスト失敗（例外を上げる）メソッド（testBrokenMethod）を追加。

残りTODO

• [] テストメソッドが失敗したとしてもtearDownを呼び出す
• [] 複数のテストを走らせる
• 収集したテスト結果を出力する
• [] 失敗したテストを出力する ◀︎ TODO追加

小さいテストを足そう

テストを実行すると、"raise Exception"をキャッチしていないため、落ちてしまう。
Exceptionをキャッチして記録するようにしたいが、（ステップが大きいので）一旦棚に上げて、もっと小さいテストを足そう。

第22章へ >>