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

章3 シンプルなホームページのテスト 単体テストで

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

前章では機能テスト（FT）が失敗し、 サイトのホームページのタイトルに「To-Do」を含めるよう要求していることが分かった。 さあ、アプリケーションの開発を始めよう。 この章では、最初のHTMLページを作成し、URL処理について発見し、 Djangoのビュー関数を使ってHTTPリクエストへのレスポンスを作成する。

警告：ここからが本番だ

最初の2章は意図的に軽く扱った。ここから先は本格的なコーディングに入る。予言しておくが、どこかの点で間違いが起きるだろう。私の説明と異なる結果が出るはずだ。これは良いことだ。なぜなら、これは真の「真の文字形成の学びの体験™」となるからだ。

一つの可能性は、私の説明が曖昧だったため、意図したものと異なることを実行したケースだ。一歩引いて、本書のこの段階で何を達成しようとしているのか考え直そう。どのファイルを編集しているのか、ユーザに何ができるようにしたいのか、何をテストしているのか、その理由は何か？間違ったファイルや関数を編集していたり、間違ったテストを実行している可能性がある。 指示通りにコピー＆ペーストが順調に進む時よりも、こうした「立ち止まって考える」瞬間から、TDDについて多くを学べるはずだ。

あるいは本当のバグかもしれない。粘り強く、エラーメッセージを注意深く読み（ 「トレースバックの読み取り」参照）、 原因を突き止めろ。 たぶんカンマの抜け、 スラッシュの忘れ、 Seleniumのfindメソッドのsの抜けくらいだろう。 だがZed Shawが『Learn Python The Hard Way』で強く主張したように、デバッグも学習に不可欠だ。 だから諦めるな！ 本当に詰まったらいつでもメールしてくれ。デバッグを楽しめ！

最初のDjangoアプリと最初の単体テスト

Djangoはコードをアプリ単位で構造化することを推奨している。 理論上、一つのプロジェクトに複数のアプリが存在し得る。 他者が開発したサードパーティ製アプリを利用でき、 別のプロジェクトで自身のアプリを再利用することさえ可能だ…​とはいえ 正直なところ、後者は私自身やったことがない！ それでもアプリはコードを整理する良い方法だ。

ToDoリスト用のアプリを始めよう：

$ python manage.py startapp lists

これでリストというフォルダが作成される。manage.pyや既存のsuperlistsフォルダの隣に配置され、その中にはモデルやビュー、そして我々がすぐに必要とするテスト用のプレースホルダーファイルがいくつか含まれる：

.
├── db.sqlite3
├── functional_tests.py
├── lists
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── manage.py
└── superlists
    ├── __init__.py
    ├── asgi.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

単体テストと機能テストの違い ...