Pythonによるテスト駆動開発, 3rd Edition

第2章. unittestモジュールを使った機能テストの拡張

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

現在のテストはデフォルトのDjango「it worked」ページを確認しているが、これを修正しよう。代わりに、サイトの実際のフロントページで確認したい要素をチェックするテストにする。

さて、どんなウェブアプリを作っているのか明かす時だ：ToDoリストサイトだ！分かってる、分かってる。ネット上のウェブ開発チュートリアルはどれもToDoリストアプリか、 ブログか投票アプリだ。 俺も流行にしっかり乗ってる。

理由は、ToDoリストが実に良い例だからだ。 最も基本的な形では、文字列のリストという非常にシンプルな構造だから、 「最小限の機能を持つ」リストアプリを簡単に動作させられる。 しかし様々な方法で拡張できる——異なる永続化モデル、 期限やリマインダーの追加、他のユーザとの共有、クライアントサイドUIの改善などだ。 「ToDo」リストに限定する必要もない。 どんな種類のリストでも構わない。 重要な点は、ウェブプログラミングの主要な側面すべてを 示せること、そしてそれらにTDDをどう適用するかを 示せることだ。

機能テストで最小限の実用アプリを 範囲設定する

Seleniumを使ったテストは実際のウェブブラウザを操作できるから、 ユーザ視点でアプリケーションがどう動くかを実際に見られるんだ。だから機能テストって呼ばれるんだよ。

つまりFTはアプリケーション仕様書のような役割を果たす。 いわゆるユーザストーリーに沿って、 ユーザが特定機能を操作する流れと、 アプリがどう応答すべきかを追跡する傾向がある。¹

用語説明： 機能テスト == エンドツーエンドテスト == 受け入れテスト

私が機能テストと呼ぶものを、エンドツーエンドテストと呼ぶ人もいれば、 やや頻度は低いがシステムテストと呼ぶ人もいる。

重要な点は、この種のテストがアプリケーション全体の機能を 外部から検証する点だ。 別名としてブラックボックステストや クローズドボックステストがある。 テスト対象システムの内部構造を一切知らないためだ。

他にも「 受け入れ テスト 」という名前付けを好む者もいる（「受け入れテストについて」参照）。この区別は、テストやシステムの粒度レベルというより、テストがユーザに見える機能（つまり動作）の「受け入れ基準」をチェックしているかどうかに関わっている。

機能テストには人間が読めるストーリーが必要だ。 テストコードに付随するコメントで明示する。新しいFTを作成する際は、まずコメントを書くことでユーザストーリーの要点を捉えられる。 人間が読める形式だから、非プログラマーと共有することも可能だ。 アプリの要件や機能を議論する手段として活用できる。

テスト駆動開発とAgile／リーン開発手法はしばしば組み合わされ、そこで話題に上るのが最小限の実用アプリだ：有用性を保ちつつ構築できる最もシンプルなものは何か？まずはそれを構築し、できるだけ早く反応を確かめよう。

最小限の実用可能なToDoリストは、ユーザがToDo項目を入力し、次回訪問時にそれを記憶しておく機能さえあれば十分だ。

functional_tests.pyを開き、以下のようなストーリーを書いてみよう：

functional_tests.py (ch02l001)

from selenium import ...