API Testing について。
Playwright 1 で API Testing を組み立てており、 TestRail 2 と連携させる。
Playwright は複数の Report 機能 3 があり、それを TestRail に表示させることができる。
最近は E2E の実践のために、本を読みながら Playwright で遊んでいる。
AWS CDK との格闘の合間の休憩として 🍵
本の購入は BENTO
にお世話になっている。thank you kubell
前提
- テスト管理ツールとして TestRail を利用している。
- VS Code の Dev Containers を利用している。
- 開発言語は TypeScript である。
Installation
- TestRail の CLI は Python が必要。
- TypeScript に Python を追加しているため、 Python を仮想化する。
Python 3.11.2
TestRail CLI v1.9.5
python3 -m venv .venv
source .venv/bin/activate
pip install trcli
- Playwright のテスト結果出力時の
name
を設定する。
PLAYWRIGHT_JUNIT_SUITE_NAME="Automated API Tests Run"
- Playwright でのテストはこちら。
- TestRail の Parameters を定義する。Command Line の Option として渡すこともできる。
host: https://fakename.testrail.io/
project: My TestRail Project
project_id: 1
username: myuser@name.com
password: StrongP@ssword
file: ./test-results/junit-report.xml # 相対パス
title: Playwright Automated Test Run
Here we go!!
trcli -y -c ./config.yml parse_junit
(.venv) root ➜ /workspaces/hogehoge/web-api-tests (BPD-493) $ trcli -y -c ./config.yml parse_junit
TestRail CLI v1.9.5
Copyright 2024 Gurock Software GmbH - www.gurock.com
Parser Results Execution Parameters
> Report file: ./test-results/junit-report.xml
> Config file: ./config.yml
> TestRail instance: https://mycompany.tmxtestrail.com/ (user: daisuke.yamamoto@example.com)
> Project: My Poroject
> Run title: Playwright Automated Test Run
> Update run: No
> Add to milestone: No
> Auto-create entities: True
Parsing JUnit report.
Processing JUnit suite - Automated API Tests Run
Processed 1 test cases in section customer-companies.spec.ts.
Checking project. Done.
Creating test run. Test run: https://mycompany.tmxtestrail.com/index.php?/runs/view/5
Adding results: 1/1, Done.
No attachments found to upload.
Submitted 1 test results in 2.9 secs.
(.venv) root ➜ /workspaces/hogehoge/web-api-tests (BPD-493)
Conclusion
「みんなが心地良いペースで働いてはいけない」
10年以上 JTC にいた身からすると、「速さ」に違和感を感じることもあった。
ベンチャーに身を置くようになり、成功かどうか分からないものを確かめる「速さ」が重要だと思うようになった。
なぜなら、どれだけ綺麗に作ったものでも価値が無ければただの自己満足に過ぎないと思うからだ。
そして、「速さ」の中でも一定の品質のものを作るのが Professional だと思う。
コミュニケーションのコストを抑えて速く作るなら、極論一人で作った方が速い。
一方で、作ったものに価値があるとわかった時に、それを成長させるならチームが必要だと思う。
100 個の挑戦を「時計を支配」しながら進めることができる manager を集めることができれば、そのうち 1 つは成功を掴めるかもしれない。
そんな環境に身を置いているという自覚を先週の出張で感じ取ることができた。