E2Eテストにおけるwipという扱いについて
E2EテストのWIPの扱い
チームでは、E2Eテストで開発途中のシナリオはWIPという扱いをしています。
ここでは、E2EテストにおけるWIPの取り扱いについての学びについて書いていこうと思います。
開発途中だからWIPをつけるというフロー
チームでは開発途中のE2EにはWIPを付与する運用をしています。
開発途中だからWIPをつけること自体には問題はないですが、
これが、既存のE2Eに対してWIPをつけているのか、もしくは新規機能開発で作成したシナリオに対してWIPをつけているのかで大きく変わってくるのではないかと思います。
新規開発のシナリオにWIPをつける
これは、新規機能の開発を行う際に、新しいE2Eテストを書いていくため、既存のテストにも影響がない。
そのため実装途中でも他のE2Eが通ればcommitしても良いと判断できます。
# New Scenario
## Admin Login
tags: wip
* User must login as "admin"
* Navigate to the configuration page
既存のシナリオにWIPをつける
新しい要件が加わったことで、既存のE2Eに修正を加える必要が出てきたため、テストを一時的にWIPにする
これは、これからも通っていてほしいテストを一時的に対象外にすることを意味しています。
# Existing Scenario
## Admin Login
tags: wip
* User must login as "admin"
* Navigate to the configuration page
+ * New Step
対象外にすることで、本来CI上で実行されていたシナリオが流れなくなるということです。
本来であれば、リリースされているシナリオは実行されるべきだと思います。
既存のシナリオにWIPをつけるには？
既存のシナリオにWIPをつけるには大きく二つ方法があります。
- diffを出して運用する
- 別のシナリオとして定義する
1. diffを出して運用する
純粋にdiffを出していく。E2Eが完成するまではcommitもしないような運用です。
ペアプロを採用していることもあり、一コマ毎にペアを変えていきます。
そうすると、どうしても完了できない状態が出ててきた時に、diffを出して引き継ぎます。
diffを出して、引き継ぐだけなので差分も引き継ぎやすい一方
コンフリクトが起きる可能性も高くなる
→実質ブランチ運用しているような状態に近い認識でいます。
2. 別のシナリオとして定義する
既存のシナリオに修正を加えていくのではなく、別のシナリオとして追加する
既存には手を加えないため、別シナリオで実装を進めている中で既存のE2Eに影響が出ているかWatchできます。
コミットはしやすいですが、最終的に一つのシナリオにマージするため
wipを外し忘れる可能性があります。
# Existing Scenario
## Admin Login
* User must login as "admin"
* Navigate to the configuration page
+ ## Admin Login
+ tags: wip
+ * User must login as "admin"
+ * Navigate to the configuration page
+ * New Step
ちなみにチームでは、こちらを採用しています。
→diff運用の方がコストが高いと判断したためです。
もちろんシナリオをマージしないとけないという伸びしろがあるので
これはこれで対応は検討しないと行けないところです。
まとめ
WIPの運用について今回学んだこととして
- なんとなくwipを使わない
- 既存にwipをつけるならdiffるか、頑張ってコミットする
- 別シナリオにするならwipを外し忘れないこと
Discussion