はじめに
はじめまして、HITOTSU株式会社の河村康治です！
これまでE2EテストはGaugeで実施していたのですが、だんだんとGaugeが辛くなり、Playwirghtに移行しました。
今回はGauge→Playwrightに移行した時の経緯を記事に残していこうと思います！！
Gaugeいいじゃん！って思ったとき
GaugeはMarkDown形式でシナリオが記載でき、ユーザのシナリオが自然言語にかけるのはいいなと思い採用しました。また自然言語にかけることで、ユーザシナリオをPDMが作成し、シナリオを元にDevがテストコードに落とし込む事ができるので、役割分担ができます。
MarkDownと実際のテストコードの結び付け方も簡単で、Markdown形式のspecファイルに書いた内容を@Stepのメッセージと紐づいているだけです。(下記画像のような感じです)
Gaugeはデフォルトでブラウザ操作ツールはtaikoでしたが、Playwrightの方が扱いやすいなと思い、Gauge✖️Playwrightという構成に着地しました。
Gauge✖️Playwrightで実装が固まった時は、おお、これはいいぞ！！とワクワク感が止まらなかったです。
あー、Gauge辛いなぁと感じる
実際にE2Eテストの運用を実施していくと、Gaugeでのいくつかの課題が出てきます。
Specファイルではテストコードの戻り値を管理できない
ブラウザで登録作業を実施した場合、管理IDが表示されたとします。
その場合次のStepでも利用したいので呼び出し元に返却します。ただ、GaugeはMarkDown形式のテキストファイルです。戻り値をそもそも管理できる機構がないのです。
あれ？？この値どうやって管理すればいいの？次のStepでも使いたいのだが。。。となる。回避策として、グローバルインスタンスを作成し、そこで値を管理する機構を作ることになります。このグローバルインスタンスをどのようなフォーマットで保持しておくのがいいのかというのも、頭を悩ませるポイントの1つでした。
再利用性を考慮した結果、テストケースの意図が伝わりにくくなる
異なるユースケースだけど、同一の関数を利用したい場合ありますよね。
ただ、マッピングファイルはspecファイルと同等のテストケース名で紐づけているので、1個変更すると動かなくなります。対策としては、specファイルの内容を抽象化する or 同様の関数を追加するかです。流石に、同様の関数を追加するのはナンセンスなので、specファイルの内容を抽象化することになります。ただ、せっかく具体的な内容を記載してわかりやすくしたのに、抽象化するのはもったいないなぁと感じます。
脱Gaugeに向けた対応
CodeceptJSを触ってみました。触った感触としては悪くなかったんですが、これだったらPlaywright1本でよくない？って結論になりPlaywright1本で実装することにしました。
参考