色々なコードの書き方に「あぁ、これは〇〇パターンだな」って思えるとそれがアンチパターンだとしてもなんかカッコいいですよね。
また、他の人と話すときに「この部分は〇〇パターンを適応した方がよいのでは？」みたいな話ができると齟齬が少なくなりそうです。
Seleniumデザインパターン＆ベストプラクティスという本を読んで、「とりあえずSelenium IDEで記録するか」という方法がレコード＆プレイバックパターンと紹介されていてこのことを強く思いました。
この本には自分があんまり馴染みのなかったパターン名が紹介されていたので、ここで紹介したいと思います。
Record and Playbackパターン
ユーザが通常おこなう活動を記録しておき、それをテストツールを通して再生できるようにするというパターン。
利点
- すぐ作成できる
- プログラミング言語が書けなくてもテストを作成できる
欠点
- 吐き出されるコードの可読性が低い
- 仕様変更に脆い
- テストとデータが密結合
- コードベースのメンテナンスは至極悪い
スパゲッティパターン
テストの実行順序に依存し、各テストがプライベートなコンポーネントを共有し独立していない。1つのテストケースが1つのテストか、絡み合った複数のテストを表しているのかわからないようなアーキテクチャや設計が認識できないパターン。
利点
- すぐに取り掛かれる
- コードベースが小さくなる（他のテストの処理に依存するため、重複する処理を省略できる）
欠点
- 密結合している
- 順序をランダムにできない
- テストを並列に実行できない
- 失敗の発見が遅れる（1テストケースで複数のテストをおこなっているため）
- テストの可否が他のテストに影響する
DRYテストパターン
DRY原則（Don't Repeat Yourself）を取り入れたパターン。
重複したコードを取り除くだけでなく、重複したテスト目標も取り除く。
利点
- 重複を取り除く
- テストがモジュール化される
- 保守性が高くなる
欠点
- プロジェクト構造が複雑になる
- 絶えず管理する必要がある
- プログラミングスキルが要求される
Hermeticテストパターン
スパゲッティパターンの対極で、各テストが完全に独立しているパターン。
他のテストや制御できないサードパーティ製サービスへの依存も排除する。
利点
- クリーンな状態で開始できる
- テストの可否が他のテストに影響しない
- ランダム実行できる
- 並列実行できる
欠点
- 事前の設計が必要になる
- 実行時間が長くなる（各テストで環境をセットアップするため）
- 使用リソースが増加する
Black Hole Proxyパターン
サードパーティにまつわる不確実性を取り除いてテストを安定させるパターン。
利点
- 速度が改善される
- テストが安定する
欠点
- レイアウトが壊れる（SNSボタンなどに依存していた場合）
- サードパーティコンテンツのテストができない
まとめ
本で紹介されていたパターンを少し紹介しました。
本で紹介された利点・欠点をコードなしに紹介しているためよくわからない箇所もあるかと思いますが気になりましたら続きは本で📚
なぜ、私がこの内容にしたかというとレコード＆プレイバックやスパゲッティコードにすらパターンという接尾語を与えると利点と欠点があり、どのパターンで進めていくのか考慮するときの選択肢としての１つとしてなり得るのだなと感嘆したからです。
本の中ではスパゲッティパターンから徐々にHermeticテストパターンに書き換えていく流れや他の様々なパターンが紹介されています。
データ駆動テストや振る舞い駆動テスト（BDD）などを適用してテストスイートの育て方が書かれていて面白かったのですが、一番印象に残ったのは名前を付けることの大切さです。
facebookのソーシャルプラグインを削る時に「Black Hole Proxyパターンを適用しましょう」で共通認識できればなんかイケてない？って感じで少し上がりますよねｗ
あなたの無意識に行っているコードやテストもどこかに名前が与えられていないパターンが存在するかもしれませんよ。