【ITニュース解説】Learning TDD by doing: Is Umbraco's management API the answer to acceptance testing?

TDD（テスト駆動開発）は、システム開発においてテストを先に書くことで品質と設計を向上させる手法であり、システムエンジニアにとって重要なスキルである。TDDには、個々のプログラム部品が正しく動作するかを検証する「単体テスト」と、システム全体がユーザーの期待通りに動作するかを検証する「受け入れテスト」がある。筆者はこれまで単体テストには習熟してきたが、特にUmbracoというコンテンツ管理システム（CMS）を使ったアプリケーションにおいて、受け入れテストの実現に課題を感じていた。この記事では、その課題の背景と、Umbracoの新しい管理APIがどのようにこの問題を解決しうるかという考察が示されている。

受け入れテストとは、システムがユーザーの視点から見て期待通りに機能するかどうかを確認するテストである。ユーザーがウェブブラウザでウェブサイトを閲覧するのと同様に、実際にシステムをデプロイした環境で、実際のブラウザを使ってテストを実行することを目指す。このテストの目的は、様々なシナリオとユーザー操作をシミュレートし、ユーザーが意図したタスクを実行できることを検証することにある。しかし、この受け入れテストの実現には大きな困難が伴う。

最も重要な困難は、テストを実行する前にシステムの状態を予測可能で一貫したものに保つことである。テストは常に同じ初期状態から始まるべきだ。もしテスト中にシステムのデータが不規則に変化すると、テストの結果が不安定になり、信頼できないテストになってしまう可能性がある。例えば、「関連コンテンツブロック」が特定の内容を表示するかどうかをテストする場合、その関連コンテンツのページ群が事前に定義され、テスト中に変更されないことが必須となる。他のテストが同時並行で実行されたり、データのクリーンアップが不完全だったりすると、テスト結果に影響を与え、意図しない失敗を引き起こすことがある。

UmbracoのようなCMSにおいて、システムの状態とは、ウェブサイトのコンテンツ、画像や動画などのメディアファイル、設定されたドメインや言語、そして場合によっては会員情報など、非常に多岐にわたる。受け入れテストを行うには、これらの要素を含む「コンテンツツリー」と呼ばれる情報構造を、テストごとに一貫して作成・管理できる必要がある。この課題に対し、これまでは主に二つのアプローチが考えられてきた。

一つ目は、テストの実行ごと、またはテストのセットごとに、全く新しいデータベースとウェブサイトの環境を構築する方法だ。この方法は、複数のテストを並行して実行する際に非常に有効である。しかし、オンデマンドで新しいウェブサイトとデータベースを作成し、テスト後にこれらを確実にクリーンアップする能力が求められるため、インフラの構築と管理が非常に複雑になるという課題がある。

二つ目は、単一のウェブサイトとデータベースを使い、各テストの実行前、またはテストのセットごとに、コンテンツツリーを完全にリセットする方法である。このアプローチでは、テストは順番に実行される必要があるが、ホスティング環境のセットアップは比較的単純になる。また、各テストのセットアップの一部としてクリーンアップが行われるため、後から個別にクリーンアップ作業を行う手間が省ける。しかし、もしクリーンアップが適切に行われなかった場合、テストの不安定性につながる可能性がある。筆者の場合、テストごとに新しいウェブサイトやデータベースをオンデマンドで作成することは現実的に不可能だったため、単一環境でのコンテンツシナリオ設定がより現実的な選択肢となった。

では、単一のUmbracoウェブサイト上で、どのようにして予測可能なコンテンツシナリオを設定するのか。プログラムによって現実の環境にコンテンツを設定するためには、「セキュアなマシン間認証」と「バックオフィスを操作するためのHTTP API」という二つの要素が必要となる。Umbraco 13の時代には、これらの両方を開発者が自力で構築する必要があり、その労力に見合うものではなかったため、現実的な選択肢とは言えなかった。しかし、Umbraco 16では、この状況が大きく変わった。

Umbraco 16では、バックオフィスの「ユーザー」セクションで、通常のユーザーに加えて「APIユーザー」を作成できるようになった。APIユーザーは、通常のユーザーと同じ権限モデルに従うが、マシン認証のためのクレデンシャル（認証情報）を作成できる点が特徴だ。これにより、セキュアなマシン間認証という最初の要件が満たされる。

このAPIユーザーのクレデンシャルを使用することで、Umbracoの「管理API」に接続できるようになる。管理APIは、Umbracoのバックオフィスの状態、つまりコンテンツやメディア、その他のあらゆる設定をプログラム的に管理するためのインターフェースである。通常のユーザーがバックオフィスで手動で行うのと全く同じように、APIを通じてコンテンツの作成や変更が可能となるのだ。この管理APIを活用することで、テストごとに一貫したコンテンツツリーを自動的に構築できるようになる。

さらに、UmbracoはOpenAPIという標準仕様に準拠しているため、これを利用して独自のAPIクライアント（APIと通信するためのプログラム）を自動生成できる。筆者は、C#のクライアント生成ツールであるNSwagStudioを使って、このようなAPIクライアントを生成することに興味を示している。管理APIのクライアントが利用可能になれば、信頼性の高い受け入れテストの作成が現実のものとなるはずだ。

具体的なテストの例として、筆者は以下のようなコードを想定している。「given（準備）」フェーズで、Scenarioというビルダーを使ってテストの開始条件を定義する。例えば、「基本的なコンテンツが存在し、かつ特定の詳細ページがSEOタイトルで上書きされている」といった状態を構築する。このBuildAsync()メソッドの呼び出しが、Umbracoの管理APIと通信し、必要なコンテンツを自動的にセットアップする役割を果たす。次に、「when（実行）」フェーズで、Userオブジェクト（これはSelenium WebDriverなどのツールによって実装されることが想定されている）が、設定された詳細ページを実際に訪問する動作をシミュレートする。そして、「then（検証）」フェーズで、Assert.Equal()のようなアサーションを使って、ページのタイトルが期待通り「Title overwritten by SEO」になっていることを検証する。これは単体テストフレームワークであるxUnitにおける古典的な検証方法だ。

もちろん、この例は表面的なものであり、「基本的なコンテンツのセットアップ方法」や「シナリオビルダーの具体的な仕組み」、「ユーザー操作の実装方法」など、まだ多くの未解決な部分が残っていることは筆者も認めている。しかし、これらの課題も十分に解決可能であるという確信を持っているようだ。

結論として、Umbracoの管理APIは、実際の環境での受け入れテストを実現するための非常に有望なツールであると筆者は考えている。APIユーザーと組み合わせることで、テストシナリオをプログラム的に設定するための統合ポイントが提供される。これはこれまで困難だったUmbracoアプリケーションの受け入れテストの実現に大きな一歩となる可能性を秘めている。筆者は今後のさらなる探求に強い意欲を示している。