はじめに
本記事は、アジャイル開発手法におけるQAの参考になれば、と作成しました。
開発、QA、また今後、それらに携わっていく方々の即戦的知識になればと思います。
また、本記事で作成したソースコードは下記に公開しています。
https://github.com/EIKINAKAYAMA/cypress-demo
そもそもテストって？
システム開発では、システムがリリースされるまで、
作成された開発物に問題がないかを色んなテストでチェックします。
- UIテスト
- ブラックボックステスト
- 負荷テスト
- リグレッションテスト
- 退行テスト
- 受け入れテスト
- アドホックテスト
etc...
上記は一部を載せていますが、まだまだ沢山あります。
会社や組織によって呼び方が変わったり、テストというよりもテスト手法だったり、同じようで厳密には内容が異なったりと多種多様のテストが存在し、必ずしも全てのテストを実施しているわけではなかったりします。
これだけ様々なテストがありますが、ざっくりと下記の3種に分けることができます。
この3種類のテストを経てリリースされることが、現在のデファクトスタンダードとなっています。
引用元: https://www.qbook.jp/academy/curriculum/0001/lessons/ad00003/
-
単体テスト（UT：Unit Test）
- 関数やメソッド単位で、正しく機能するかをテスト。
- JUnit(Java), PHPUnit(PHP),Jest(JavaScript)などのフレームワーク利用しテスト。
- 基本、開発者・QAエンジニアの領域。
- ”A”という文字か表示できているか、”計算が正しくできてるか”というレベル。
-
結合テスト（IT：Integration Test）
- コンポーネント単位で、正しく機能するかをテスト。
- テスト設計や手法に基づいて、漏れなく打検。
- 基本、QAの領域。
- ”決められた選択肢を選択した後、意図したポップアップが出るか”というレベル。
-
システムテスト（ST:System Test）
- 完成された開発物全体で、要件を満たしているかをテスト。
- テスト設計や手法に基づき、漏れなく打検。
- 基本、QAの領域。
- "ログインから購入まで問題なく完了できるか"というレベル。
以上が通称、V字モデルの右側に該当する箇所となっています。
引用元: https://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB
テスト自動化について
さて近年、アジャイル開発手法が流行しています。
高速開発手法と呼ばれるものですね、、、
あまり着目されてないですが、高速開発ということは、本来高速テストでもあるべきです。というよりそうであるのが理想です。
特に、開発変更箇所が1だったとしても、テストは100実施することが望ましいと考えると、超々々々スーパー高速テストを実施してあげるべきです。
ここで爆成長を遂げたのが、テスト自動化です！！！！!
引用元: 民衆を導く自由の女神（ドラクロワ：ルーブル美術館)より
テスト自動化は、文字どおりテストを自動化することです。
つまり上記で記載した「V字モデル」の右側を人ではなく、システムにやらせようということです。
？？？？？？？？？
百聞は一見にしかずなので、実際に動くものを作ってみてみましょう！
Cypressとは
と、その前に今回、自動テストを構築するにあたってCypressというNode.jsを利用したJavaScriptのテストフレームワークを使います。
詳細については、公式サイトや他の記事でご参照ください。
公式サイト（https://docs.cypress.io/guides/overview/why-cypress）
Quiita記事（https://qiita.com/eyuta/items/a2454719c2d82c8bacd5）
簡単に特徴を挙げておきます。
メリット
・環境構築が楽、CI連携が楽、動作が軽い
（Web WebDriver API経由ではなく、ブラウザ上でランナーが動く）
・e2eテスト（UT~STの全てがテスト可能）
・クロスブラウザ対応（chrome、chromium、edge、electron、firefox）
・DOMが出現するまで、自動でリトライ
・Javascriptイベントをテストコード側でlistenすることが可能
・multi-domain対応（ドメインまたぎのテストが可能）
デメリット
・テスト特化、スクレイピングはできない
・Javascript（Typescript）以外の言語は対応されていない
・複数のブラウザウィンドウの同時操作ができない。チャットのテスト等はできない
実際に動かしてみると特徴が理解しやすので、いざ初めて行きましょう！！！
環境構築
使用ツール バージョン一覧
- node v18.2.0
- cypress v9.6.0
1. Node.jsをインストールする。
2. テストしたいアプリケーションを入れる。
テストしたいアプリケーションを導入します。
本記事では、Reactのアプリケーションを入れてみます。
npx create-react-app cypress-demo
npm run start
3. 作成したアプリをリモートリポジトリをPUSHする。
4. Cypressをインストールする。
$ npm install cypress --save-dev
$ npx cypress open
するとこのような形で、Cypressが動いているのが確認できます。
5. CI内でCypressを実行するコマンドを追加作成します。
"scripts": {
"cy:open": "cypress open",
"cy:run": "cypress run"
}
5. テストファイルを作成する。
こちらは、作成されたアプリケーションや実施したいテストによって、任意に変更ください。
本記事は、Reactで作成されたデフォルトの画面を対象テストしています。
cypress/integration配下にあるファイルがテストファイルです。
サンプルコード
/// <reference types="cypress" />
describe('test demo', () => {
beforeEach(() => {
// Port番号は各アプリケーションに応じて変えてください。
cy.visit('http://localhost:3000')
})
it('text check', () => {
// containsは、画面に指定の文字が含まれているか否かをテストします。文字は任意に変更ください。
cy.contains('Learn React')
})
})
6. いざテスト開始！
$ #with browser
$ npm run cy:open
$ # OR
$ #headless
$ npm run cy:run
実行結果
| cy:open | cy:run |
|---|---|
 |
 |
7. CI内でLocalサーバーが立ち上がるまで待機させる構成を入れる。
手順6までは、Localサーバーを立ち上げてからテストしましたが、CI内ではLocalサーバーが立ち上がっていることを判定して、テストを実施する必要があります。
本記事は、ReactのBuildされたファイルを対象にしています。
CI用のテスト実行コマンドのポート番号、サーバー起動コマンドは、必要に応じて変更ください。
$ #判定ライブラリのインストール
$ npm install start-server-and-test --save-dev
$ #サーバー起動ライブラリのインストール(*必要があれば)
$ npm install serve
CI用のテスト実行コマンドを追加
"scripts": {
"ci": "start-server-and-test 'serve -s ./build' 3000 'cy:run'"
}
実行すると、サーバーが立ち上がってからテストが始まるのが確認できるはずです。
$ npm run build
$ npm run cy:ci
8. CI(GitHub Actions)をセッティングする。
今回は、GitHub連携が不要なGitHub Actionsを使いたいと思います。
GitHubのリポジトリにあるActionsのタブから「set up a workflow yourself」を押下して、yamlファイルを作成します。
name: build and cypress test
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: run ci command
run: |
npm install
npm run build
npm run ci
9. PRを作成してCommit！。
これをCommit, Pushすると、CIが走ります。
あとは、眺めているだけで自動でテストしてくれます。
実行結果 OKの場合
実行結果 NGの場合
今回はシンプルなテストでしたが、テストを入れていけば活躍間違いなしです。
その他の自動化
今回は、Cypressを利用して構築しましたが、
色々な自動化ツールがあるので、ご自身の環境にあったツールを利用して自動化構築を構築してみてください！
おわりに
テスト自動化は9割が失敗するという記事があるように、失敗例が多いです。
個人的には、下記のいずれかを満たすと失敗しそうだなと感じました。
・コードのメンテナンスコストと、テスト自動化範囲のバランスが悪い。
・1つのPR内に開発変更と自動テストの変更が入らない。(作成者が違う等の理由により)
・データが固定化されていない。
これから導入を考えている方の参考になればと思います。