はじめに
CIでE2Eテストを回すときに、問題となるのは実行時間です。
弊社で用意しているE2Eテストはすべてのテストケースを実行するのに40〜50分かかります。
これを毎Push、毎Pull Requestごとに実行するのはちょっとつらいです。
開発ブランチにおいては、修正した箇所のみE2Eテストを実行できたら嬉しいですよね。
LIFULLのSETGで使っているテストツールBuckyには実行対象となるテストケースをラベルで絞り込む機能があります。
今回はそのBukcyのラベル機能とGitHubのPull Requestのラベルを組み合わせることで、テストしたい部分にだけCI上でE2Eテストをかけられる仕組みを考えました。
テストを実行する範囲のイメージとしてはこんな感じです。
※リグレッションテストの効果が薄まるので、統合環境ではすべてのテストを実行するようにしましょう。
テスト対象
テスト対象はBuckyのテスト結果表示アプリケーションであるBucky-Managementを使います。
Bucky-Managementは以下の5つのページが存在します。
- トップ
- テスト結果一覧
- テスト結果詳細
- テストスイート一覧
- テストスイート詳細
テスト作成
それではBuckyでテストを作成していきます。
このようにyamlでテストケースを作成することができます。
Buckyの使い方に関してはこちらをご覧ください。
https://qiita.com/rueyjye/items/570ce17d698819f99091
desc: トップ画面に関係するテスト
device: pc
service: bucky_management
priority: high
test_category: e2e
labels: TOP #ラベルを指定
cases:
- case_name: top_1
func: 右上のグラフのタイトル表示
desc: 右上のグラフのタイトル表示の検証
procs:
- proc: open page
exec:
operate: go
url: <%= ENV['BUCKY_FQDN'] %>/
- proc: 右上のグラフのタイトルが「Latest Result e2e-pc」であること
exec:
verify: assert_text
page: top
part: title_e2e_pc
expect: Latest Result e2e-pc
注目していただきたいのはlabels: TOPの部分です。
ラベルを記入しておくことで、テスト実行時にオプションを指定すればこのテストケースのみ実行できるようになります。
上記のテストケースと同様に他のページでもテストケースを作成しておきます。
それぞれのテストケースにラベルも記入してあります。
.
├── result_detail.yml # テスト結果詳細
├── result_list.yml # テスト結果一覧
├── suite_detail.yml # テストスイート詳細
├── suite_list.yml # テストスイート一覧
└── top.yml # トップ
GitHub Actions
CIはGitHub Actionsを使います。
作成したWorkflowは以下です。
name: System testing
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Cache docker image of Bucky-Management
uses: actions/cache@v1
with:
path: ~/caches
key: ${{ runner.os }}-build-${{ hashFiles('Dockerfile') }}
restore-keys: |
${{ runner.os }}-build-${{ hashFiles('Dockerfile') }}
- name: Build and save docker image
run: |
if [ ! -f ~/caches/images.tar ]; then
docker build -t bucky-management . --build-arg rails_env=development && \
mkdir -p ~/caches && \
echo 'tar start'
docker save bucky-management -o ~/caches/images.tar
echo 'tar finish'
fi
run:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Cache restore
uses: actions/cache@v1
with:
path: ~/caches
key: ${{ runner.os }}-build-v3-after-${{ hashFiles('Dockerfile') }}
restore-keys: |
${{ runner.os }}-build-v3-${{ hashFiles('Dockerfile') }}
- name: Docker load
if: steps.cache.outputs.cache-hit != 'true'
run: |
docker load -q -i ~/caches/images.tar
- name: Create docker network and run and setup BM
run: |
docker network create bucky
docker-compose -f docker-compose.bucky.yml up --build -d
sleep 10
- name: Migrate and insert test data
run: |
docker exec -i bm-app rails db:create
docker exec -i bm-app rails db:migrate
docker exec -i bm-app rails db:fixtures:load
- name: Clone test codes
run: |
mkdir /opt/bucky-core
git clone https://github.com/hikimochi/bucky-testing.git /opt/bucky-core
- name: Run bucky-core
run: |
cd /opt/bucky-core
docker-compose up --build -d
sleep 5
- name: Execute testing
run: docker exec -i bucky-core bucky run -D pc -d -l $(cat $GITHUB_EVENT_PATH | jq -r '.pull_request.labels[].name')
jobs-build
Bucky-Managementイメージのキャッシュを作成しています。
Cache docker image of Bucky-Management
ここではBucky-Managementイメージのcacheを作っています。
テストを実行するときにプロダクトコードをマウントし、アプリケーションサーバを立ち上げる仕組みをとることでDockerfileを書き換えない限りは再ビルドしなくて済むようになります。
Build and save docker image
キャッシュヒットしないときはBucky-Managementコンテナをビルドし、特定のディレクトリにsaveしています。
jobs-run
実際にテストを実行するジョブです。
GitHub Actionsではneedsを使うことでジョブの前後関係を作ることができます。
Cache restore
buildジョブで生成したcacheをリストアします。
Docker load
docker saveされたimageをloadします。
machineのimages内にbucky-managementという名前でloadされます。
Create docker network and run and setup BM
Bucky-Managementを立ち上げるためのネットワークを作成し、docker-composeでアプリケーションを立ち上げます。
ウェブサーバとしてnginx、データベースとしてmysqlコンテナを使います。
docker loadでbucky-managementイメージがローカルに展開されたので、image: bucky-managementで指定できるようになります。
Migrate and insert test data
データベースのマイグレーションとテストデータの格納を行います。
テスト実行の度にテストデータはきれいに作り直す仕組みをとっています。
Clone test codes
ここからはBucky-Coreでテストを実行するための準備を行っていきます。
テストコードをクローンします。
Run bucky-core
Bucky-Coreを実行するためにコンテナを起動します。
先程作成したネットワーク内で立ち上げることで、machineの影響を受けずcontainer_nameで名前解決できます。
Execute testing
実際にテストを実行する部分です。
bucky run -l [ラベル名]で指定したラベルを持つテストを実行できます。
$GITHUB_EVENT_PATHに関しては次で紹介します。
構成としてはこの様になっています。
GITHUB_EVENT_PATH
GitHub Actions以外のCIツールではPull Requestのラベル情報をとってくるにはGitHub APIを使う必要があります。
GitHub ActionsではGITHUB_EVENT_PATHにそのビルドに関係する情報がjson形式で格納されます。
今回はその情報をjqで処理することで、ラベルの情報のみ取り出しています。
cat $GITHUB_EVENT_PATH | jq -r '.pull_request.labels[].name'
実際に使ってみる
ここではBucky-ManagementのTOP画面を改修したという想定です。
Pull Requestの作成時にラベルを付与します。
※本来のラベルとは違うラベルの使い方をしているのでラベルはテスト用だとわかるようにしたほうが良いと思います。例）「TEST: TOP」など
ビルドではこのように指定したラベルのみ実行されます。
今回使用したコードはこちらで管理してますのでよかったら参考にしてください。
今後の展望
今回はBucky-Managementをテスト対象としましたが、より大きな開発規模のものにおいては、QAと開発者のドメイン知識の差をラベルを通して埋めることにも繋げられると思っています。
プロダクトコードとラベルの対応をストアすることで、プロダクトコードが製品のどの領域（ラベル）に紐付いているかの情報が溜まっていきます。
QAは開発者に聞かなくてもある程度の情報はプロダクトコードとラベルの情報から得られることになります。
また、それを元に実行するテストを自動的に判別することも可能になります。
例えば、複数の開発者で修正が起こるfoo.rbに対してラベルでの運用がある程度行われたとします。
| ファイル名 | ラベル名 | 使用数 |
|---|---|---|
| foo.rb | TOP | 2 |
| LIST | 18 | |
| DETAIL | 80 |
このようなデータがある中で、ラベルが付与されていないPull Requestにおいてfoo.rbが改修されたときはDETAILのラベルがつくテストを実行する仕組みを作れば、修正ファイルに応じたテストの自動選択を実現することができます。
確率的に選べばより網羅的なテストができて良いかもしれませんね。
次回はこの仕組みを実際に構築した記事を書きたいと思います。
それでは良いお年を！