第19章 前準備

[at-grandpa]

TODO

• テストメソッドを呼び出す
• setUpを最初に呼び出す
• tearDownを後で呼び出す
• テストメソッドが失敗したとしてもtearDownを呼び出す
• 複数のテストを走らせる
• 収集したテスト結果を出力する

[at-grandpa]

二つの変更（setupの追加とsetupの呼び出し）を行ったが、TDDは１つずつやったほうがよい。

[at-grandpa]

シンプルにできるのは、他のテストがグリーンの時だけだ。

これはclimのリファクタリングでも学んだ。

[at-grandpa]

WasRunのインスタンスを test_running でも test_setup でも生成しているので、今実装したsetupを使って重複を排除する。

[at-grandpa]

TODO

• テストメソッドを呼び出す
• setUpを最初に呼び出す
• tearDownを後で呼び出す
• テストメソッドが失敗したとしてもtearDownを呼び出す
• 複数のテストを走らせる
• 収集したテスト結果を出力する

[at-grandpa]

ここまででやってることの言語化。

• TestCaseクラスはテストケースのスーパークラス
  • setupのabstract class
  • runで、指定されたメソッドを呼び出す
• WasRunクラスは「指定メソッドがrunするかをテストするためのテストケース」
  • だからTestCaseクラスを継承している
• TestCaseTesstクラスは、今回のTDDのテスト
  • TestCaseクラスのテストをしている
  • ちゃんと「methodをrunしているか」「setupは呼ばれているか」をテストしている

[at-grandpa]

振り返り

• テストをシンプルに書けるほうがパフォーマンスよりも大事だという意思決定を行った。
  • オブジェクトの重複生成の件
• setUp メソッドのテストと実装を行った。
• setUp メソッドを使ってテスト対象コードであるサンプルテストケース(WasRun)をシンプルにした。
• setUp メソッドを使ってサンプルテストケースのチェックを省き、テストコード(TestCaseTest)をシンプルにした(自分で脳外科手術をするよう だと言ったのを覚えているだろうか)。

[at-grandpa]

この章で得た知見。

• よっぽど出ない限り、パフォーマンスよりもテストがシンプルに書けて、依存関係が無く、順序が変わっても大丈夫なようにする