xUTP Topics: 第二回 xUnit Test Patterns の世界観「テストコードの不吉な臭い」
- 書いた人
- @yujiorama(id:yujiorama)
目的
この連載記事の目的は次のような感じです。
- xUTP読書会で得られた知見を整理する
- xUnit Test Patterns に書かれている内容を分かりやすい形で広める
英語の壁も、難しさの壁も、読書会の有志による努力によって取り払われました。
軽い気持ちで、xUnit Test Patterns に挑戦してみましょう。
はじめに
私見ですが、分量の多い本なので、全体像を掴んでから興味のありそうなところを つまみ読みするのがよいのではないか、と思っています。
前回は表紙の裏に記載されている、「テスティングパターンの一覧」について示しました。
今回は裏表紙の裏に記載されている、「テストコードの不吉な臭い一覧」と「逆引きテスティングパターン」 を紹介したいと思います。
例によってリンクはxUTP読書会Wikiから辿れるようになっています。 リンクの無いものは、独立した章にはなっていないものの、文中で触れられているキーワードとなります。
テストコードの不吉な臭い一覧
「テストコードの不吉な臭い」とは、マーティン・ファウラーのリファクタリングでも触れられている 「リファクタリングが必要であるような腐ったコード」のテストコード版です。
例えば、テストコードが増えてくるにつれて、プロダクトコードと合わせて修正する対象が増えてしまい、 結果として生産性が低下してしまうという経験はよくあることでしょう。
xUnit Test Patterns では、そういった傾向を「不吉な臭い」と呼び、パターンとして分類しています。
「テストコードはあるのに何故かうまくいかない」という状況になったら、見直してみる価値はあると思います。
- Assertion Roulette
- テストが失敗した際、どのアサーションで失敗したのか分かりにくいテストメソッド。
- Buggy Tests
- バグが定期的に見つかるような自動化テスト。
- Conditional Test Logic
- 条件によって実行されたり、されなかったりするコードが含まれているテスト。
- Developers Not Writing Tests
- 開発者が自動化テストを書いてくれない。
- Erratic Test
- あるときは成功したりまたあるときは失敗したりといった不安定なテスト。
- Fragile Test
- SUT のテストに関係のない部分を変更したはずなのに、テストがコンパイルできなくなったり失敗するようになったりする。
- Frequent Debugging
- テストが失敗する原因を調べるのに手動のデバッグが必要なテスト。
- Hard-to-Test Code|
- テストを書くのが難しいコード。
- High Test Maintenance Cost
- メンテナンスしていくのに大きな手間のかかるテスト。
- Manual Intervention
- 実行するたびに人が何かの操作をしなければならないようなテスト。
- Obscure Test
- 一瞥して理解できないくらい難しいテスト。
- Production Bugs
- 形式的なテストや商用環境で検出された多くのバグ。
- Slow Tests
- 実行にとても長い時間のかかるテスト。
- Test Code Duplication
- 同じようなコードが繰り返し書かれているテスト。
- Test Logic in Production
- テストのときだけ実行されるロジックをプロダクションコードに埋め込んでしまったテスト。
逆引きテスティングパターン
私達の開発するシステムは、規模も複雑さもまちまちです。
しかし、本質的には同じような構造を有しているものが多くあります。
これは、テストコードにも同じことが言えます。
そこで、直面している問題について本質を見抜き、適切なテスティングパターンを選択することで、 良いテストコードを書くことができるようになるでしょう。
なお、SUT とは System Under Test の略語で、本文で頻出する単語です。 具体的には、開発しているシステムを構成するコンポーネントの中で、テストコードが対象としているものを指します。
- 私達のソフトウェアについて自動化テストを書くには何を準備すればよいのですか？
- Recorded Test (278)
- Scripted Test (285)
- Data-Driven Test (288)
- どうやったらテストを書いたり実行するのを簡単にできますか？
- Test Automation Framework (298)
- テストコードはどこに配置すればいいですか？
- テストメソッドをテストケースクラスにまとめるにはどうしたらいいですか？
- テストの自己チェックはどうしたらいいですか？
- テストロジックはどうやって構造化すればよいですか？
- Four-Phase Test (358)
- Assertion Message (370)
- Unfinished Test Assertion (494)
- テストコードの重複を取り除くにはどうしたらいいですか？
- Data-Driven Test (288)
- Custom Assertion (474)
- Test Utility Method (599)
- Parameterized Test (607)
- テストをどうやって実行したらいいですか？
- Test Runner (377)
- Testcase Object (382)
- Test Suite Object (387)
- Named Test Suite (592)
- テストランナーが実行するテストをどうやって選択すればよいですか？
- Test Discovery (393)
- Test Enumeration (399)
- Test Selection (403)
- どのフィクスチャー戦略を使うべきでしょうか？
- Minimal Fixture (302)
- Standard Fixture (305)
- Fresh Fixture (311)
- Shared Fixture (317)
- フィクスチャーをどうやって構築したらよいですか？
- In-line Setup (408)
- Delegated Setup (411)
- Creation Method (415)
- Implicit Setup (424)
- 最初のテストメソッドが共有フィクスチャーを必要とするまで構築を遅らせるにはどうすればいいですか？
- Prebuilt Fixture (429)
- Lazy Setup (435)
- Suite Fixture Setup (441)
- Setup Decorator (447)
- Chained Tests (454)
- テストコードで使用する値 (定数) はどうやって決めればよいですか？
- Dummy Object (728)
- Literal Value (714)
- Derived Value (718)
- Generated Value (723)
- フィクスチャーを破棄するにはどうしたらいいですか？
- スローテストを避けるにはどうしたらいいですか？
- Shared Fixture (317)
- Test Double (522)
- Fake Object (551)
- 条件に基づくテストロジックを避けるにはどうしたらいいですか？
- ロジックだけを独立して検証するにはどうしたらいいですか？
- Back Door Manipulation (327)
- Layer Test (337)
- Test Double (522)
- Test Stub (529)
- Test Spy (538)
- Mock Object (544)
- Fake Object (551)
- Stored Procedure Test (654)
- 振る舞いを検証するにはどうしたらいいですか？
- テストダブルに任意の返り値や期待値を指定するにはどうしたらよいですか？
- コードをテストしやすくするにはどうしたらよいですか？
- Humble Object (695)
- Test-Specific Subclass (579)
- SUT が動的に依存先を置き換えられるようにするにはどうしたらよいですか？
Keyword(s):
References:[xUTP Magazine 0002号] [ぺけま]