を読んだ。僕はGebでPage Objectを作るのが結構好きなので、このブログ記事の主張の理由を知りたくて読んだ。そして納得した。
## Cypress
Cypressについては今朝書いた。
CypressでもPage Objectを使えはするんだけど、Page ObjectよりもApp Actions（自分たちが名付けた手法）の方が良いよ！という主張。
## Page Object Pattern
Page Object Patternについては、この辺か
この辺かな
https://www.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern
## 言ってること
Page Objectの問題は
- メンテナンスが大変
- テスト対象も状態を持っているのに、別の状態を持ち込んでしまう
- 条件分岐をテストに持ち込んでしまう（これはCypressの主張的にはアンチパターン）
- UI経由で操作をするので遅い
ということで、Cypressは Application Actions という手法を提案
- アプリケーションの状態を変更するのにUIを経由せずに、JSの関数を作ってそれを使うようにする
そうすることで
- メンテナンスするPage Objectレイヤーがなくなる
- 条件分岐がなくなる
- UIを経由しないので操作が速い
となるよと。
## 感想
- CypressがターゲットにしてるのはSPAだなと再確認。メリットやデメリットの話がSPA前提になっている。
- SPAの場合、Page Objectを使わない方が良いというのは分かる。Pageとリクエストが一対一に対応していない場合が多いだろうから。
- SPAは状態をクライアント側で持つので、CypressがJSを直接操作できるという強みが活かせる
- テスト対象の状態を用意するために、UIを操作して状態を更新するのではなく、直接JSを操作して状態を用意することができるので速い
Cypressならではの強みを活かした主張だなぁという感じ。で、Cypressを使う場合にはそれに従っておいたら良いのかなと思った。ただ、実際に業務で使ったことがあるわけじゃないので、今は頭の中だけの話。
一方でこういうところに気をつける必要がありそう
- テストとテスト対象が強く結びついてしまう。テストのためだけに状態を更新できるようにしないといけないかもしれない。
- end-to-endテストなのに、仕様じゃなくて実装のことを理解して作らないといけない。
- UIからの操作ではたどり着かない状況を裏側で作りだして、そこに対してテストをしてしまう、といった意味のないテストをしてしまうかもしれない
これも頭の中だけの話。
## 結局Page Objectはどうなの？
で、結局Page Objectはどうなの？というところだけど
- SPAじゃない場合
- Page Objectを使って良いと思う。十分メリットがある。
- CypressでもPage Objectは使えるけど、Cypressを使うならCypress流の方（Page Objectを使わない方）が良いかなとは思う。
- SPAの場合は
- Cypressを使う場合は、Page Objectは使わずに、内部状態を直接更新する関数を使う方が良さそうに思った
- Seleniumを使う場合も、Page Objectじゃなくて良さそうかな。状態をUI経由で更新する関数を用意したら良いのかな。
面白かったー。
