【ITニュース解説】Cloud Resume Challenge — Testing the Serverless Backend with Playwright and Python

システムエンジニアを目指す皆さんにとって、ソフトウェア開発におけるテストは非常に重要な工程である。今回は、個人の技術スキルを証明する「Cloud Resume Challenge」というプロジェクトを例に、サーバーレスなアプリケーションのバックエンド部分をどのようにテストし、その品質を確保していくのかを具体的に解説する。

このプロジェクトの目的は、自身の履歴書をウェブサイトとして公開し、その過程でクラウド技術を学ぶことにある。特に、ウェブサイトの訪問者数をカウントし、それを表示する機能の裏側にある「サーバーレスバックエンド」のテストに焦点を当てる。サーバーレスとは、開発者がサーバーの管理を意識せずにアプリケーションを構築できる仕組みを指し、ここではAWS Lambdaというサービスで動くプログラムと、DynamoDBというデータベースサービスが使われている。

テストツールとしてPlaywrightが選ばれた理由から説明する。Cloud Resume Challengeでは、テストツールとしてCypress（JavaScriptベース）かPlaywright（Pythonベース）のどちらかを選ぶことができた。筆者はPlaywrightを選択した。そのシンプルな理由は、プロジェクトのメイン言語がPythonだったからである。訪問者数をカウントするLambda関数がPythonで書かれているため、テストコードもPythonで書くことでプロジェクト全体の一貫性を保つことができた。PlaywrightのPython APIは分かりやすく、ドキュメントも充実しており、Pythonの標準的なテストフレームワークであるpytestとの相性も非常に良いというメリットもある。

次に、どのような種類のテストを行うべきかについてである。大きく分けて二つのテスト方法が推奨されている。一つは「単体テスト（ユニットテスト）」で、これはLambda関数のロジックなど、個々のプログラム部品が単独で正しく動くかを検証するものである。この際、DynamoDBのような外部サービスとの連携部分は「モック」（偽物のデータや動作）を使って一時的に置き換え、Lambda関数自身の処理だけを独立してテストする。しかし、この方法では実際のインフラストストラクチャ全体が正しく連携しているかは確認できないという限界がある。もう一つは「スモークテスト」または「エンドツーエンドテスト」である。これは、アプリケーションがデプロイされた後、実際のAPIのURLに対してテストを実行する方法である。このテストでは、Lambda関数だけでなく、APIリクエストを受け付けるAPI Gateway、データが保存されるDynamoDB、そしてそれらを連携させるための権限設定（IAMパーミッション）といった、システム全体の構成要素が全て連携して期待通りに動作するかを検証できる。筆者はこのスモークテストとエンドツーエンドのブラウザテストを選んだ。実際の環境で全体を検証する方が、システムの安定性をより確実に確認でき、また面接などの場で技術的な話題を提供する際にも価値が高いと考えたためである。

Playwrightのセットアップは比較的簡単である。まず、Pythonのパッケージ管理ツールであるpipを使ってpytest-playwrightとrequestsというライブラリをインストールする。requestsはAPIとの通信に使われる。次に、Playwrightがブラウザを操作するために必要なChromiumというウェブブラウザをインストールする。コマンドはpip install pytest-playwright requestsとplaywright install chromiumである。開発環境をCodespaceのようなクラウドベースの環境で利用している場合、環境が再構築されるたびにこれらのツールが自動的にインストールされるように、設定ファイルに"postCreateCommand": "pip install pytest-playwright && playwright install chromium"のような記述を追加しておくと便利である。

実際のテストコードはtests/test_resume.pyというファイルに記述された。大きく分けて二種類のテストが含まれている。

一つ目の「APIスモークテスト」では、主にバックエンドAPIの動作を確認する。 まず、test_api_returns_200()では、APIにリクエストを送信した際に、サーバーから「200 OK」という正常な応答が返ってくるかを検証する。これはAPIが正常に稼働しているかを確認する基本的な健康チェックである。 test_api_returns_views_key()では、APIからのレスポンスデータの中に「views」というキー（訪問者数を示す項目）が含まれているかをチェックする。これにより、APIが正しい形式のデータを返していることを確認する。 test_api_views_is_integer()では、「views」キーの値が整数型であるかを検証する。データが正しい型で提供されていることは、後続の処理でエラーを起こさないために重要である。 test_api_views_increments()では、APIを連続して呼び出すたびに、返される「views」の値が1ずつ増加するかを確認する。これは訪問者カウンターの主要なロジックが正しく機能しているかを検証する。 test_api_views_greater_than_zero()では、「views」の値が0より大きいかを検証する。これは、データベースが正しく初期化され、訪問者数が記録されていることを確認するテストである。

二つ目の「エンドツーエンドブラウザテスト」では、Playwrightを使ってウェブブラウザを自動操作し、ユーザーが実際にウェブサイトを閲覧する際の挙動を確認する。 test_resume_page_loads()では、仮想ブラウザで履歴書ウェブサイトのURLにアクセスした際に、ページが正常に読み込まれ、HTTPステータスコードが200であることを確認する。これは、ウェブサイトのコンテンツを配信するCloudFront（コンテンツ配信ネットワーク）とS3（オブジェクトストレージサービス）が正しく機能していることを検証する。 test_resume_has_title()では、読み込まれたウェブページにタイトル（<title>タグの内容）が設定されているかをチェックする。これにより、ウェブサイトのHTMLが適切にレンダリングされていることを確認する。 test_visitor_counter_displays()は最も価値のあるテストの一つである。このテストでは、ウェブページにアクセスした後、訪問者カウンターが表示されるまで待ち、そのカウンターの値が数字であるかを検証する。このテストが成功することで、ブラウザがページを読み込み、JavaScriptがバックエンドAPIから訪問者数を取得し、その数字をウェブページ上に正しく表示するという、一連の複雑な処理全体が問題なく機能していることを一度に確認できる。

これらのテストは、ローカル環境でpytest tests/ -vというコマンドを実行することで実行できる。筆者の場合、最初の実行で全ての8つのテストが問題なくパスした。

自動テストの真価は、それを自動的に実行することにある。そこで、これらのテストを「CI/CDパイプライン」に組み込むことが重要となる。CI/CDとは、継続的インテグレーションと継続的デリバリーの略で、開発者がコードを更新するたびに自動的にビルド、テスト、デプロイが行われる一連のプロセスを指す。GitHub Actionsのようなツールを使って、このパイプラインを構築する。 具体的には、GitHub Actionsのワークフロー設定ファイルに、Playwrightと必要な依存関係をインストールするステップと、テストを実行するステップを追加する。これにより、コードをGitHubのリポジトリにプッシュ（アップロード）するたびに、以下のプロセスが自動的に実行されるようになる。まず、GitHubへのプッシュがトリガーとなり、更新されたファイルがS3に同期される。次に、CloudFrontのキャッシュが無効化され、新しいコンテンツが配信されるようになる。その後、インフラストラクチャの変更があればTerraform（インフラ管理ツール）が適用され、最後に今回追加したPlaywrightのテストが実行される。全てのテストがパスすれば「緑色のチェックマーク」が表示され、システムが正常に動作していることが確認できる。このように自動化することで、手動でのテストの手間を省き、エラーを早期に発見し、常に高い品質を維持することが可能になる。

この一連のテスト実装から得られる主要な学びはいくつかある。サーバーレスな環境では、単体テストよりも、実際のデプロイ済みAPIに対して実行するスモークテストが非常に有効である。これにより、Lambda、API Gateway、DynamoDB、そして必要なIAM権限が全て連携して正しく機能するかを一度に検証できる。また、Playwrightとpytestの組み合わせは、クリーンなAPIとPython開発者にとって馴染み深いツール群を提供し、テストコードを書きやすく、拡張しやすいという点で非常に優れている。そして、テストはローカルで実行するだけでなく、CI/CDパイプラインに組み込んで、コードが変更されるたびに自動的に実行されるようにすることが不可欠である。これにより、ソフトウェアの品質を継続的に確保し、開発プロセスの効率を大幅に向上させることができる。特に、訪問者カウンターのテストは、ブラウザからデータベースまでのシステム全体の連鎖をたった一つのアサーション（検証）で確認できるため、その価値は非常に高い。