より良いエンジニアを目指して

1日1つ。良くなる!上手くなる!

読書感想 単体テストの考え方/使い方

優れたテストスイートの特徴

  • テストすることが開発サイクルの中に組み込まれている
  • コードベースの特に重要な部分のみがテスト対象となっている
  • 最小限の保守コストで最大限の価値を生み出すようになっている

いつかの職場で部長が、

全てフルパス、テストコード書くべきだよね

みたいなことを言っていたのを思い出します。無理です。

古典学派とロンドン学派

これ、言葉で説明するのは難しいですね。

ぼくはどちらかというと古典学派です。

ロンドン学派はテストしたいクラスが依存するクラスはモックにすることになり、かなり厳密です。ここまでテストするのはなかなか大変な気がしますね。

AAAパターン

テストコードの、Arrange-Act-Assertの3段階のフェーズのことを指します。

本書で紹介するテストコードは実際に

// Arrange

// Act

// Assert

とコメントを書いて紹介しています。

また、各テストケースはプロダクションコードが解決しようとしていることを語るべきとしています。

確かにテストケースは、書いた人しか何をしているかわからないということになりがちです。

本書がxUnitを推す理由

  • xUnitの方がわかりやすくシンプル。
  • [TestFixture]属性のようなテストクラスにつけなくてはならない属性は存在していない。
  • publicなクラスであれば、どのようなクラスであっても単体テストを含められる。

良い単体テストを構成する4本の柱

単体テストの手法

  • 出力値テスト
  • 状態の確認テスト ... プロパティなどをテストする
  • コミュニケーションベーステスト ... モックを使って動作が行われたかをテストする

コミュニケーションベーステストは、ロンドン学派では使われるそうですが、やはり、モック使って、そこまでするのはデータベースとか直接通信するのが難しい場合ではないと、なかなかという気がしますね。

privateなAPIのテスト

  • 原則的にすべきではない。privateなAPIは実装の詳細であり、壊れやすいから
  • テストしたいのに、publicなAPIからテストできないのは抽象化が足りていないと考えた方が良い。
  • テストのために、APIを公開するのはNG