見出し画像

【STAC2024】E2Eテストの作成から行うTDDの実際

SHIFT Group 技術ブログ

はじめに

こんにちは。テスト自動化アーキテクトの牧野です。

先日、ソフトウェアテスト自動化カンファレンス2024 に登壇し、E2Eテストの作成から行うTDDの実際 のタイトルで、公開できそうだった社内向けプロジェクトの風景をお話ししました。 本記事ではその講演の内容をブログ化し、よりカジュアルにTDDの実際を知ることのできる記事となります。

また、登壇の動画は【STAC2024】E2Eテストの作成から行うTDDの実際 - YouTube にて公開されています。ぜひ再生数を増やしてください。

本記事で学べる事

  • E2E自動テストをプロジェクトに導入する動機

  • E2E自動テストをプロジェクトに導入する効果

  • E2E自動テストを導入したプロジェクトの開発フロー

  • E2E自動テストを作る際のコツ

  • E2E自動テストで楽をするための心構え

  • E2E自動テストを活用した可視化

プロジェクト背景と概要

本記事では、JSONとスプレッドシートの相互変換を行うアプリケーションを開発した際に、Playwrightを活用してE2Eテストを作成しながら進めたプロジェクトの実例を紹介します。開発初期に自動テストを導入することで得られた利点や工夫について詳しく解説します。

プロジェクト概要

目的：JSONデータを効率的かつ正確に操作するためのツールとして、JSONとスプレッドシートを相互変換するアプリを開発しました。このツールは、スプレッドシートのデータを簡単にJSON形式に変換でき、エラーを最小限に抑えることを目指しています。

対象ユーザー：スプレッドシート操作に慣れているノンプログラマー（例： コピペなどの基本的なPC操作が可能な方）。

開発環境：

  • ユーザー、開発者ともにMacを使用

  • 使用技術: Electron + TypeScript + Playwright

テストの利用者はプログラマー

  • ステークホルダーにレポートを見せる事はある

  • テストケースの説明は求められない

  • レポートが理解してもらえれば、ドキュメントは求められない

非常に自由が利く、素敵なプロジェクトです。

自動テストの役割・導入の動機

ゴールを明確にしたい

自動テストを導入することで、各タスクの明確なゴールを設定し、進捗状況を可視化します。

開発初期の段階では、タスクのゴールが曖昧になりがちですが、自動テストを設計するプロセスそのものがゴール設定を具体化する手助けとなります。

「本当に正しいものを作っているのか」「この機能は何ができるようになり、役に立つのか」
このような懸念をなくし、モチベーション向上・維持も期待できます。

また、自動テストの成否によりリリース可否を明確にすることで、リリースサイクルの信頼性向上・高速化を実現し、高品質なソフトウェアの低コストなリリースを実現します。

楽をしたい

人の力を使わず、機械の力でテストを完了させ、開発時間を最大化します。開発時間はあればあるほどよいので。

また、ケースそれぞれの知識を必要とせずテストを完了できるなど、テスト実行の難易度を下げます。
ユーザーストーリーの成否判断は難易度が高く、時間が過ぎれば何が正しいのかあやふやになってしまいます。自動テストにすることで知識と正しさを保存し、テスト実行がローコストかつ簡単な状態を維持します。

以上の取り組みにより、テストは何度でも正しく行うことができ、楽に品質を維持できるようになります。

開発フロー

おおまかなフローは以下の通りです。

全体

  1. ストーリーの洗い出しとポイント見積もり

  2. イテレーション計画

  3. ストーリーごとに開発

  4. マージ後、次のストーリーへ進行

  5. イテレーション完了後、リリースブランチの保存

  6. リリースノートの公開とアプリケーションの配布

ストーリーごとの開発内訳

  1. ストーリーブランチ作成

  2. 自動テスト作成（E2Eまたはユニットテスト）

  3. マージリクエスト作成、テストコードレビュー

  4. プロダクトコード実装

  5. 作成したE2Eでテスト

  6. プロダクトコードPush

  7. MRでレビュー

  8. マージ後に全E2Eがパスするかテスト

  9. マージ

以上の流れはおおまかかつ、最低限のやることで厳守すべきワークフローではありません。たとえば、プロダクトコード作成中に相談があったらいったんPushしてMR上で会話するなど、書いていないステップが発生することもあります。また、既存機能の組み合わせでうまいことできそうで、それを実証する自動テストの作成だけでよさそうだったらプロダクトコード実装はスキップすることもします。

開発チームの足がとまらず、メンバーのパワーが出ればOKです。みんな良い大人なのでギチギチしなくてもうまいことやってくれます。

最初のE2E

目的：プロトタイプのデモンストレーション

開発初期にPlaywrightを用いてE2Eテストを構築することで、完成品のイメージをステークホルダーに共有し、プロジェクトの初期ゴールを明確化します。

実装のコツ

  1. デザインは簡素でOK：
    初期のUIは簡単なボタンやテキストボックスのみで十分です。Playwrightで基本機能をエミュレートしたテストを構築し、動作のイメージを共有します。
    具体的には、以下記事で紹介しているようなUIをはじめに用意しました。スプレッドシートコピペインターフェースのご紹介 ｜SHIFT Group 技術ブログ

  2. 破棄前提でスピード重視：
    初期のプロトタイプでは「何が必要か」が明確でないため、とにかく動くものを優先して開発します。必要に応じて後からプロトタイプを改良、または流用すれば問題ありません。

  3. テスト成功をプロジェクトの軸に：
    主要機能を保証するE2Eテストは、常に成功させ続けるようにします。このテストが成功している限り、ゴールに向けてブレることがありません。

  4. メンテナンスも忘れずに：
    初期のコードがシンプルでも、開発が進むにつれて柔軟に更新します。例えば、input.valueに直接値を代入していた処理を、コード全体で再利用できる形に改善するなどです。

「プロトタイプ」の例

ストーリーごとのE2E

実装のコツ

  1. こだわらないのがコツ
    頑張っていろいろ考慮しても正解である保証はありません。いまいちだなと思ったらあとで調整すればよいのです。試行錯誤しやすくなるのが自動テストのメリットです。

  2. 開発中にE2Eを見直すこともある
    開発が進み、具体的なものが出てきたタイミングほどアイディアがでます。開発中にE2Eを見直すべきと感じたら見直します。 この手戻りを問題のある手戻りと感じたことはありません。E2Eテスト作成も含め開発です。 ただ、スケジュールを考慮して「今回はここまで！あとは新規ストーリー！」のような割り切りは必要です。

  3. E2Eを作るだけのストーリーもある
    既存機能で達成できる場合、それを確認するE2Eを作成し、テストケースが増えプロダクトコードが一行も増えなくとも、開発ストーリーを完了とすることもあります。プロダクトがユーザーストーリーを実現できることを調べられ、継続的に保障できることにも価値があります。

  4. ツールが実現することを可視化する
    レポートにプロダクトが実現できるストーリーが増えていくのは楽しいです。 ステークホルダーに報告できる成果が多いと非常に都合もよいです。

参考に、はじめに書いたE2Eの要点の再現を以下に記載します。こういうものでもよいでしょう。

test('ユーザーは1ボタンでスプレッドシートからJSONを作ることができる', async()=>{
   await page.fill("#csv","foo\tbar\nabc\t1");
   await page.click("#run");
   await expect(page.locator("#result").inputValue()).toBe(JSON.stringify({foo:"abc",bar:"1"}));
});

E2Eで楽をするために

テスト実行コマンド以外の知識を求めない

今回は npm run gui-test をテスト実行コマンドとし、これ以上の知識を求めず clone -> init -> build -> run gui-test で開発が始められる状態をキープし続けました。

これは実際に体験しないとわかりづらいかもしれませんが、ワンコマンドテスト実行は予想以上に偉大です。

E2Eの範囲はユーザーストーリー網羅にとどめる

E2Eの実行コストが高いことを受け入れ、向き合うことが重要です。E2Eの網羅性が高すぎると楽をできません。

網羅性はUTで担保することにしました。UTはプログラマが「気になること」を確認するものとします。なんだかんだ製作者とその隣のプログラマが作るUTは、よくプロダクトを見ています。

E2E成功 = リリースOKをキープ

リリース基準をチームが迷わない状況を維持します。チームメンバーがだれでもリリースできる状況を作りやすくなり、プロジェクト運営が想像以上に柔軟かつ楽になります。

自動テスト導入のメリット

  1. 進捗の可視化：
    テスト結果でストーリーの達成度を共有できるため、チーム全員がプロジェクトの状況を把握できます。ステークホルダーにも進捗を説明しやすくプロダクトが解決できる課題が分かりやすいため、信頼を得ることができます。

  2. 開発者間のコミュニケーションが円滑に：
    自動テストコードを「ホワイトボード」のように使い、「この仕様でどう？」と具体的な議論が可能になります。

  3. アイディアが出やすく、取り入れやすい：
    自動テストが通ればOKの状況にすることで、変化への恐れが少なく、「E2Eが通ればよいか」を合言葉に新しいアイディアを取り入れやすくなります。

まとめ

Playwrightを活用してE2Eテストを早期に導入した結果、仕様の明確化やチームの合意形成がスムーズに進みました。特に、テストを中心に開発を進めることで、安心感を持ってプロジェクトを進行できた点が大きな成果でした。

アプリ開発において、PlaywrightやE2Eテストの導入を検討されている方に、ぜひこの事例を参考にしていただければと思います。

執筆者プロフィール：牧野 真哉
自動テストで生計を立てています

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのCodioful (Formerly Gradienta)

最後まで読んでくださり、ありがとうございます！

御社サービスのご相談はお気軽に。
ソフトウェア品質のプロがお伺いします。