slow tests
TRANSCRIPT
Slow Tests第8回xUTP読書会大中浩行(せとあずさ)
2010年9月11日土曜日
症状• テストを流すのに時間がかかる
• SUTの変更ごとにテストを流さなくなる
• テストを流すたびにおしゃべりしたり、シューティングゲームに興じたり...
2010年9月11日土曜日
影響• Slow Testsは生産性を下げる
• ボトルネックとなる部分が”integration
token”となる
• 集中力が削がれる
• テストが実行されてから、バグに気づくまでの時間が浪費される
2010年9月11日土曜日
• 一般的な対処はShared Fixtureだが、この対処は大抵Erratic Testsを生み出す
• もしShared Fixtureを使用しなければならないのなら、可能な限りFixtureを不変なものとして作成するべき
2010年9月11日土曜日
トラブルシューティング• Slow Testsは、SUTがビルドされるたびにテストが行われるのが原因
• 原因が明確でないなら、スムーズに走るものと時間がかかるものを別のサブセット(もしくはサブスイーツ)に分けて走らせることができる
2010年9月11日土曜日
• プロファイリングツールは有用
• setUpメソッドとtearDownメソッドにログ出力を仕込むことによってプロファイリングすることもできる
2010年9月11日土曜日
原因• SUTをビルドする方法がテストを遅くするようなコーディングを強いている場合がある
• レガシーコード
• 「テストを最後に」ビルドする観点
2010年9月11日土曜日
General Fixture
• 過剰に手の込んだFresh Fixtureを共通に使っている
• General FixtureをShared Fixtureとするこによって、テストのたびに再構築されることを避ける
• Fixtureが不変でないなら、Erattic Testsを招く
2010年9月11日土曜日
非同期テスト• 1回のテストで2秒待つとして、そのようなテストが1ダースあったら?
• 非同期でないロジックをテストすることによって、非同期処理を避ける
• Humble Executableを実装することによって、テスト可能なコンポーネントを抽出する
2010年9月11日土曜日
テストが多すぎる
• 巨大なシステムで、膨大なテストが必要とされているのか...
• テスト間に重複があるのか...
• テストを走らせるのが頻繁すぎるのか...
2010年9月11日土曜日
• 常にすべてのテストを走らせる必要はありません!
• 鍵となるのは、すべてのテストが定期的に実行されている必要があるということです。
2010年9月11日土曜日
• 適切な組み合わせの部分を含むSubset
Suite をつくることを検討してください。
• Subsiteはコミット前に実行し、残りのテストは夜中に実行するようスケジューリングするなどする。
2010年9月11日土曜日
• 他の方法については、pp.319”Faster Tests
Without Shared Fixture”を参照
2010年9月11日土曜日
• システムが巨大な場合は、独立したサブシステムに切り出す
• テストの中には、他のコンポーネントに対するプロキシとして動作するものがあり、これらはインターフェースの契約に変更が加わったら、テスト側で追従する必要がある
2010年9月11日土曜日
• 疎通テストの中には、すべてのコンポーネントが協調して動くものがある場合があるが、こういうものをコミット前に動作するスイートとして含める必要はない
2010年9月11日土曜日