1. イントロダクション
- プロジェクトの概要: GoogleAnalyticsによりWebサイトのイベント計測を行う
- 課題: 導入前の課題点としてWebサイトの更新を行ったり
顧客の要望によりイベント計測を増減させたりする場合に影響の調査が上手くいっておらず
計測ができない、あるいは多重に計測されているといった不具合が発生していました。
これに対処するため、Behavior-Driven Development(BDD)を導入し、Cucumberを用いてGTMのテストを自動化しました。
2. BDDとCucumberの概要
- BDDとは何か?: BDDとは開発の前にまずテストを書くTDD(テスト駆動開発)の一種で、”ふるまい”≒仕様をテストに書くことで仕様の把握、円滑なコードへの落とし込みができるという開発手法の一種です。
- Cucumberの役割: CucumberはBDDを実現するためのツールです。
特徴的な点として、Gherkinという構文を用いることで
テストを自然言語で表わすことができるため仕様を説明するような記述が可能となっています。
ビヘイビア駆動開発 - Wikipedia
BDD Testing & Collaboration Tools for Teams | Cucumber
3. GTM作成におけるBDDの適用
例えば画面上部にあるパンくずをクリックした場合、”パンくず”をクリックした
こと、現在の階層、リンクのテキスト文字をパラメータとして送信するとします。
Cucumberでは以下のようなFeatureファイルをGherkin構文で作成します。
Feature:パンくず
Scenario:パンくずをクリックした場合イベント送信をすること
Given テストページを表示する
When パンくず"このページについて"をクリック
Then パンくずイベントが送信されること
Then 階層3が送信されること
Then リンクテキスト"このページについて"が送信されること
どうでしょうか?仕様が自然言語によりわかりやすく書かれており
構文が決められているためコードに落としやすいと思います。
4. BDDの導入による成果
- 品質の向上: 全テストを数分で行えるという安心感から大胆なリファクタリングに踏み込むことが可能になります。また、仕様変更に対しても回帰テストを行うことで影響調査が可能です。
これらは最初に課題に挙げていた点を見事に改善してくれました。 - モチベーションの向上: これは個人の感想ですが、「各シナリオが通るようなコードを作成する」ということは達成感があり楽しいです。アルゴリズムが実証できれば前述の通り、リファクタリングが可能なので目の前の目標に集中して取り組める気がします。
- コミュニケーションの改善: テストファースト全般に言えることですが、最初に振る舞いを記述することで、何を作るのかが明確になります。テスト作成の段階でレビューを行えば、実装後の手戻りが減ります。
5. 導入時の課題とその解決方法
- 設定の複雑さ:BDDの適用でも述べたGherkin構文で書かれたFeatureファイルですが
当然ですが、自然言語そのままではテスト実行できないので
(Given,When,Then)の内容をコードで記述しなければなりません。
正直この部分のコストは割高となり鬼門ですね。
今回の用途ではWebページを操作しなければしなければならないため
Selenium(Node.js)でChrome Webdriverを記述しました。 - 学習曲線: 前述の通りテストフレームワークとしてはNode.js + Selenium(Chrome Webdriver) + Cucumberという構成になっています。
フロントエンドの経験もあるエンジニアが集ってはいたもののNode.jsはノンブロッキングの仕様もありとっつきにくいようでしたので、筆者が技術的支援を行いながらテストを作成した形となります。日がたつにつれシミュレーションする動作(クリック等)をCSSセレクタで決定する等内部的にノウハウが溜まっていきスムーズになっていきました。エンジニアとしても新しい言語に触れることでモチベーションも高まり良い結果になりました。
6. 今後の展望
- さらなる改善点:今回作成したフレームワークは他のWeb開発でも応用が利きそうなので積極的に取り入れたいと思います。具体的な問題点等は時間があれば別記事に書きますが
モバイルでのテストが納得いった出来になっていません。
Node.jsの実装ではUser Agentを変更する等のAPIが実装されているのかが不明でしたので
User Agentを設定したChromeを立ち上げ直すといった工夫が必要となりました。 - GTMプレビューとの連携: GTMはその特性上デバッグを行う際に「プレビュー」といった動作をしなければならず、リンククリック時など他ページへ遷移した際にプレビューが解かれてしまうといった問題がありました。
シナリオの個別実行を行うプログラムを実装し、回避していましたが、シナリオを全実行すると上手くつながらないといったこともあったため、改修を検討したいです。
7. まとめ
- 総括: BDDによる実装は成功でした、回帰テストによるデグレの検知もできましたし
リファクタリングによるコードの軽量化、見やすさの向上もありました。 - 読者へのアドバイス: GTMを上記の方法で開発する場合イベントの送信を監視するにはバッチ送信を防ぐ等細かなコツが必要ですが、得られる効果は絶大なので是非ご検討ください。
コメント