PlaywrightでE2Eテスト作ってからElectronアプリ作った時のエピソード
前提
プロジェクト概要
JSONデータを表で一覧したりそこから実際に作れるJSONをノーミスかつ短時間で作るため、JSONとスプレッドシートの相互変換するアプリケーションを用意する
ユーザー
スプレッドシートは使えてコピペ操作など、それなりにPCを使えるノンプログラマ
開発メンバーとステークホルダー
プログラマ2 + ユーザー側1 + プロジェクトリーダーとしてスケジュール面倒見る人1
全員別人です。私はプログラマとしてカウントしています。
一応ステークホルダーとメインで話しつけたりするけど社内なんで適当にもう一人のプログラマに「ナシ付けて来い」とかやってました。
環境とテクノロジ
開発もユーザーもMac PC
Electron+Typescriptで開発してパッケージにして配布する
ワークフロー
ストーリー出し→ストーリーポイント見積→イテレーションの作業決め→ストーリーごとにブランチ作成→ストーリーを達成することを確認する自動テスト作成(E2E or UT)→プルリクエスト作成、自動テストレビューしてゴールを明確にする→プロダクトコード作成→作成したテストを通す→レビュー→マージ→次のストーリーに着手
自動テストでゴールを明確にする
自動テストの最大の目的
正直ストーリー出してる時点ではゴールは明確じゃない。その場では「だよね」みたいな雰囲気出してるけど雰囲気。誰もゴールしらない。わかってないのにわかってる空気出してるか、わかってないけどわかってると思い込んでいるだけです。
自動テスト作る段階で具体的にゴールを決めて、自動テストの成功でゴールに到達していることを確認することで明確な実装完了基準を設ける
仕様変更と自動テストの変更は同時にする
主な仕様変更のタイミングはプロダクトコードの作成
コード書いて実際にE2E通してると「この動作だるくね？」ってなることがたくさんある
その時に自動テストの変更の形で「こんなんどうすか？」と案をだしたり、相談しながらお互いに自動テストコードを変えたりで、仕様変更の具体的な内容を自動テストで決めていく
当人たちの納得感えぐいし、安心感とんでもないので本当におすすめ
最初のE2Eのコツ
目的
プロトタイプのデモンストレーション
完成品のイメージをステークホルダーに見せ最初のゴールを明確にする
雑にアプリのデモを用意する
デザインとかなんも綺麗じゃない雑にテキストボックスとボタンだけ置いたUI置いて、Playwrightで雑に基本機能の動作をエミュレートしたテストを構築する
開発速度最優先。破棄前提
プロトタイプに正しい前提なんてないので
何が正しいか、何が必要かなんて開発初期にはわからないので、とにかく動くものを作って見せて「わからせる」
わからせた後にプロトタイプが流用できるかを考えれば良い
入力は直接コードに入れておく
外部化するのは面倒だし効果も薄いので
プロトタイプなんてそんなものでよい。破棄する前提
このテストは成功させ続ける
メイン機能を保証していくため
このテストが成功している限りゴールからブレていないことが明確になるので良い。安心できる
もちろんメンテナンスしてく
最初は input.value に値突っ込んでたのをコードに移したり、機能拡充でボタンとか増えた分に対応したり、 id とかつけてセレクタよくできそうなら良くしたりとか
プロダクトコードと同レベルで更新していけ
うれしいこと
スケジュールの達成度が共有しやすい
テストの成否で実装したストーリーが見えるので。
開発メンバーどうしでも「成功してんじゃん！」で和気あいあいになれる。結構いい雰囲気で開発が進められるので気分が良い
ステークホルダーについてもめっちゃ説明しやすいしいちいち動作を見せられるので納得してもらいやすい。口出しされにくいのでめっちゃ開発に集中できる
会話がしやすい
「これこうじゃね？」って自動テストコードいじりながら会話すると、自動テストコードが実質ホワイトボードになる
プログラマ同士限定だけど、コード書いてるときプログラマしかいないので問題なし。すごい快適に会話できる
ドキュメントとかを求められにくい
動くものの説得力がすごいので、「どんなん？」って言われたらテスト結果や動作を見せればいい
ドキュメント類は結局ステークホルダーの安心感のために必要とされ開発メンバーはそこまで必要としてないのが実情なので、かなり実利がある
