Cypressを使った良く使う処理をまとめる方法

Cypressを使った共通処理のまとめ方

CypressというE2Eテストの自動化を支えてくれるツール¹があります。
Cypressをインストールし、初期設定を行うと、以下のようなフォルダ構成になっているかと思います。

cypress.json        
cypress
├── integration     
│   └── test_spec.js
├── plugins
│   └── index.js
└── support
    ├── commands.js
    └── index.js

今回は、この中のcypress.jsonとcommands.jsを使って共通化しておきたいことを記載していきます。

cypress.json

以下のように、jsonファイル内に、共通化しておきたいパラメータやURLなどを置いておきます。
自動テストを適用するのは、開発環境かと思います。その中であまりないかもしれませんが、一時的にドメインを変えて
自動テストを実行したりする時のために様々なファイルの中にあるURLやパラメータを書き換えないためにもここに記しておきます。

cypress.json

{
    "baseURL":"https://google.com",
    "UserName":"TOKITA OUMA",
    "Something":"Anything"
}

実際には、以下のように呼び出して使うことが可能です。²

test_spec.js

const baseURL = Cypress.env(baseURL);

ユーザー氏名やパスワードなど特定のユーザーを用いた動作の確認においては、動作ファイル内に置くよりも
共通化したパラメータに記載しておく方が変更が少なくて済むという点でも有効です。

command.js

自動テストを書いていると、複数の経路のテストの中で共通の処理がいくつも出てくると思います。
頻繁に使う処理であれば、モジュールとして置いておくことでテストのコードを短くできるということと
手動テストの自動化という点では、UIの変更など壊れやすさもあるため一々複数ファイルを修正するよりもメンテナンスが
楽になるというメリットもあります。

実際には、以下のように指定して作成することが可能です。³

command.js

Cypress.Commands.add('doSomething', (name) => {
  cy.get('a').contains(name).click()
  cy.get('a).type('something')
})

最後に

WEBアプリにおいては頻繁に挙動や仕様変更がある中で既存機能や画面に対する回帰テストのコストは
上がってくるかと思います。限られたケースであっても自動化しておくことでテスター自身のみならず構築する
エンジニアにとってもリリース後に不具合を出すよりかは良いかと思います。

もちろん自動テストによりテスト工数が下がるとは必ずしも言えませんが、効率的に探索テストを行えたりなど
より本質的な品質保証に向き合えるのではないかと考えています。

というわけで今回は、Cypressを用いた自動テストにおける共通処理のまとめ方でした。
Cypressに関してより良いやり方などあれば教えていただけると幸いです。

それでは、また。

1. https://www.cypress.io/ ↩

2. https://docs.cypress.io/api/cypress-api/env.html#Syntax ↩

3. https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax ↩