アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

218

ます（BDDを採用する場合は例外もあります）。開発した機能は、まず

テスト担当者が打鍵によって振る舞いを検証し、その後E2Eテストを

作成するという流れになるはずです。

すなわち、E2Eテストは万一システムの機能が退行してしまい、正し

く動作しなくなった場合にそれを検知する目的で作成します。ビジネス

ルールやビジネスロジックの細かな検証はそれに適したユニットテスト

やインテグレーションテストに任せ、E2Eテストではより高いレベルで

の検証を行うのがよいでしょう。ユーザーがユースケースを実行して目

的を達成できることを検証するのです。

●

主成功シナリオを実行できる

●

代表的な例外シナリオ、代替シナリオを実行できる

ビジネスルールのバリエーションの検証はE2Eテストで実施すべき

ではありませんが、画面操作のバリエーションはE2Eテストに含めて

おくべきです。めったに使わないボタンをクリックするとシステムエ

ラーが発生してしまった、ということは意外とよくあります。ユーザー

が画面上で行えるアクションは一通りE2Eのテストケースで確認する

のがよいでしょう。

Column

テストコードへの投資

テストコードはプロダクションコードと同様にソフトウェアの重要な資産

であると考えるべきです。テストコードはソフトウェアの内部品質を高め、

維持する上で欠かせないものだからです。

テストコード自体の可読性や保守性などの内部品質は軽視されやすく、プ

ロダクションコードと比べて多少汚くても構わないと考える人もいます。し

かし、テストコードが重要な資産であることを考えると ...