slow tests

Slow Tests第8回xUTP読書会大中浩行(せとあずさ)

2010年9月11日土曜日

症状• テストを流すのに時間がかかる

• SUTの変更ごとにテストを流さなくなる

• テストを流すたびにおしゃべりしたり、シューティングゲームに興じたり...


影響• Slow Testsは生産性を下げる

• ボトルネックとなる部分が”integration

token”となる

• 集中力が削がれる

• テストが実行されてから、バグに気づくまでの時間が浪費される


• 一般的な対処はShared Fixtureだが、この対処は大抵Erratic Testsを生み出す

• もしShared Fixtureを使用しなければならないのなら、可能な限りFixtureを不変なものとして作成するべき


トラブルシューティング• Slow Testsは、SUTがビルドされるたびにテストが行われるのが原因

• 原因が明確でないなら、スムーズに走るものと時間がかかるものを別のサブセット(もしくはサブスイーツ)に分けて走らせることができる


• プロファイリングツールは有用

• setUpメソッドとtearDownメソッドにログ出力を仕込むことによってプロファイリングすることもできる


原因• SUTをビルドする方法がテストを遅くするようなコーディングを強いている場合がある

• レガシーコード

• 「テストを最後に」ビルドする観点


General Fixture

• 過剰に手の込んだFresh Fixtureを共通に使っている

• General FixtureをShared Fixtureとするこによって、テストのたびに再構築されることを避ける

• Fixtureが不変でないなら、Erattic Testsを招く


非同期テスト• 1回のテストで2秒待つとして、そのようなテストが1ダースあったら？

• 非同期でないロジックをテストすることによって、非同期処理を避ける

• Humble Executableを実装することによって、テスト可能なコンポーネントを抽出する


テストが多すぎる

• 巨大なシステムで、膨大なテストが必要とされているのか...

• テスト間に重複があるのか...

• テストを走らせるのが頻繁すぎるのか...


• 常にすべてのテストを走らせる必要はありません！

• 鍵となるのは、すべてのテストが定期的に実行されている必要があるということです。


• 適切な組み合わせの部分を含むSubset

Suite をつくることを検討してください。

• Subsiteはコミット前に実行し、残りのテストは夜中に実行するようスケジューリングするなどする。


• 他の方法については、pp.319”Faster Tests

Without Shared Fixture”を参照


• システムが巨大な場合は、独立したサブシステムに切り出す

• テストの中には、他のコンポーネントに対するプロキシとして動作するものがあり、これらはインターフェースの契約に変更が加わったら、テスト側で追従する必要がある


• 疎通テストの中には、すべてのコンポーネントが協調して動くものがある場合があるが、こういうものをコミット前に動作するスイートとして含める必要はない


Documents