Test Smells - Slow Tests

TestComplete というテストツールを使って UI操作を自動実行するスクリプトの記述作業に、途中参加することになった。

話を聞くと、既に完成した部分では、テスト実行時間がハチャメチャに長いスクリプトになっているらしい。一つのフォームについて、合計して小一時間のテスト群があって、それが数十フォームあるから全ケースで軽く一日は超える事になる。これは、かなりのレベルの Slow Testsだと思う。

つうか、Slow Tests も困った事だが、それ以上に脱力するのが、その弊害を誰もまじめに考えて来なかったと言う点だったりする。

しかも、今までこの自動化テストを指揮してきたリーダが、同時に Coutinuous Integration に関連するチームのメンバでもあったりして、そんな人が Slow Tests という Test Smell の中でも最たるものを等閑視してきたわけだから、何かビックリしてしまう。

今まで、常時結合とかについて議論してきたのはなんだったんだろうと、こっちがしょんぼりしてしまう。Daily も無理じゃん･･･

とりあえず気を取り直して、以下、教科書どおりの処方

• 第一候補：Fake Object パターンを使って、遅い部分を置き換える。
• 第二候補：Shared Fixture パターンを使ってセットアップコストを抑える（但し、Erratic Test アンチパターンを避けるため、immutable(不変)にすること）。

教科書の方はどちらかと言うと TDD系のホワイトボックステストである一方、今度やることになるのは後付のブラックボックステストなわけで、若干状況は違うけど、原因はやはり教科書どおりの「Slow Component Usage」と「General Fixture」という事になる。毎回のログインだとか起動処理に時間が掛かっているので、つまり「General Fixture」のセットアップに「Slow Component Usage」が含まれていると言う事になるだろうか。

しかし、こういう風に後から入って行って何かを是正しようとすると、たいてい前任者の心理的抵抗に会ったりしてちょっと面倒くさい（本当はシステム開発を面白がるブログのはずなんだが、最近は愚痴の方が･･･）