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

章 ユーザー入力の保存 ：データベースのテスト

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

これまで、入力ボックスを含む静的なHTMLページを返すところまでできた。 次に、ユーザがその入力ボックスに入力したテキストをサーバに送信し、何らかの方法で保存して後でユーザに表示できるようにしたい。

この章のコードを書き始めた時、 すぐに正しい設計だと思ったものに飛びつきたくなった。 リストとリスト項目用の複数のデータベーステーブル、 新規リストと項目の追加用URL群、 3つの新規ビュー関数、 そしてこれら全てのための単体テストを6つほど。 だが、私は自分を制した。 確かに、それらの問題を一度に処理できるだけの能力は 自分にあると確信していた。 だがTDDの点は、必要な時に一つずつ処理を進めることを可能にすることにある。 だから私は意図的に視野を狭め、 その瞬間に必要なことだけを行い、 機能テスト（FT）を少しずつ前進させることにした。

これはTDDがインクリメンタルかつ反復的な開発スタイルを いかに支えるかを示す実例となる——最速の道ではないかもしれないが、最終的には確実に到達できる。¹副次的な利点として、 モデルやPOSTリクエストの処理、Djangoテンプレートタグといった新概念を 一度に詰め込むのではなく、一つずつ導入できる点がある。

これは先を見越して賢く考えるべきでないと言っているわけではない。 次の章では、もう少し設計と事前思考を取り入れ、 それがTDDとどう調和するかを示す。 だが今は、無心で突き進み、テストが指示する通りに実行しよう。

フォームをPOSTリクエスト送信用に接続する

前章の終わりで、 テストはユーザの入力を保存できていないと伝えていた：

  File "...goat-book/functional_tests.py", line 40, in
test_can_start_a_todo_list
[...]
AssertionError: False is not true : New to-do item did not appear in table

サーバに送信するため、当面は標準的なHTML POSTリクエストを使う。 少々退屈だが、確実に届けるには最適だ。本書の後半で様々なHTML5やJavaScriptを活用できる。

ブラウザにPOSTリクエストを送信させるには、次の2つの作業が必要だ：

1. <input> 要素にname= 属性を付ける。

2. これを<form> タグで囲む。² method="POST"で囲む。

フロントエンドとバックエンドの連携テスト

前回の章で、ホームページテンプレートのコンテンツに関するスモークテストを再検証すると述べたことを覚えているだろうか。ユニットテストを簡単に見てみよう：

リスト/テスト.py

class HomePageTest(TestCase):
    def test_uses_home_template(self):
        response = self.client.get("/")
        self.assertTemplateUsed(response, "home.html")

    def test_renders_homepage_content(self):
        response = self.client.get("/")
        self.assertContains(response ...