這一篇從 教程第 4 部分 結尾的地方繼續講起。我們在前幾章成功的構建了一個在線投票應用，在這一部分裡我們將為它創建一些自動化測試。
1.自動化測試簡介
自動化測試是什麼？測試，是用來檢查代碼正確性的一些簡單的程序。
測試在不同的層次中都存在。有些測試只關注某個很小的細節（某個模型的某個方法的返回值是否滿足預期？），而另一些測試可能檢查對某個軟體的一系列操作（某一用戶輸入序列是否造成了預期的結果？）。其實這和我們在 教程第 2 部分，裡做的並沒有什麼不同，我們使用 shell 來測試某一方法的功能，或者運行某個應用並輸入數據來檢查它的行為。
真正不同的地方在於，自動化 測試是由某個系統幫你自動完成的。當你創建好了一系列測試，每次修改應用代碼後，就可以自動檢查出修改後的代碼是否還像你曾經預期的那樣正常工作。你不需要花費大量時間來進行手動測試。
為什麼你需要寫測試但是，為什麼需要測試呢？又為什麼是現在呢？
你可能覺得學 Python/Django 對你來說已經很滿足了，再學一些新東西的話看起來有點負擔過重並且沒什麼必要。畢竟，我們的投票應用看起來已經完美工作了。寫一些自動測試並不能讓它工作的更好。如果寫一個投票應用是你想用 Django 完成的唯一工作，那你確實沒必要學寫測試。但是如果你還想寫更複雜的項目，現在就是學習測試寫法的最好時機了。
測試將節約你的時間在某種程度上，能夠「判斷出代碼是否正常工作」的測試，就稱得上是個令人滿意的了。在更複雜的應用程式中，組件之間可能會有數十個複雜的交互。
在更加複雜的應用中，各種組件之間的交互可能會及其的複雜。改變其中某一組件的行為，也有可能會造成意想不到的結果。判斷「代碼是否正常工作」意味著你需要用大量的數據來完整的測試全部代碼的功能，以確保你的小修改沒有對應用整體造成破壞——這太費時間了。
尤其是當你發現自動化測試能在幾秒鐘之內幫你完成這件事時，就更會覺得手動測試實在是太浪費時間了。當某人寫出錯誤的代碼時，自動化測試還能幫助你定位錯誤代碼的位置。
有時候你會覺得，和富有創造性和生產力的業務代碼比起來，編寫枯燥的測試代碼實在是太無聊了，特別是當你知道你的代碼完全沒有問題的時候。
然而，編寫測試還是要比花費幾個小時手動測試你的應用，或者為了找到某個小錯誤而胡亂翻看代碼要有意義的多。
測試不僅能發現錯誤，而且能預防錯誤「測試是開發的對立面」，這種思想是不對的。
如果沒有測試，整個應用的行為意圖會變得更加的不清晰。甚至當你在看自己寫的代碼時也是這樣，有時候你需要仔細研讀一段代碼才能搞清楚它有什麼用。
而測試的出現改變了這種情況。測試就好像是從內部仔細檢查你的代碼，當有些地方出錯時，這些地方將會變得很顯眼——就算你自己沒有意識到那裡寫錯了。
測試使你的代碼更有吸引力你也許遇到過這種情況：你編寫了一個絕贊的軟體，但是其他開發者看都不看它一眼，因為它缺少測試。沒有測試的代碼不值得信任。Django 最初開發者之一的 Jacob Kaplan-Moss 說過：「項目規劃時沒有包含測試是不科學的。」
其他的開發者希望在正式使用你的代碼前看到它通過了測試，這是你需要寫測試的另一個重要原因。
測試有利於團隊協作前面的幾點都是從單人開發的角度來說的。複雜的應用可能由團隊維護。測試的存在保證了協作者不會不小心破壞了了你的代碼（也保證你不會不小心弄壞他們的）。如果你想作為一個 Django 程式設計師謀生的話，你必須擅長編寫測試！
2.基礎測試策略
有好幾種不同的方法可以寫測試。
一些開發者遵循 "測試驅動" 的開發原則，他們在寫代碼之前先寫測試。這種方法看起來有點反直覺，但事實上，這和大多數人日常的做法是相吻合的。我們會先描述一個問題，然後寫代碼來解決它。「測試驅動」的開發方法只是將問題的描述抽象為了 Python 的測試樣例。
更普遍的情況是，一個剛接觸自動化測試的新手更傾向於先寫代碼，然後再寫測試。雖然提前寫測試可能更好，但是晚點寫起碼也比沒有強。
有時候很難決定從哪裡開始下手寫測試。如果你才寫了幾千行 Python 代碼，選擇從哪裡開始寫測試確實不怎麼簡單。如果是這種情況，那麼在你下次修改代碼（比如加新功能，或者修復 Bug）之前寫個測試是比較合理且有效的。
所以，我們現在就開始寫吧。
3.開始寫我們的第一個測試首先得有個 Bug
幸運的是，我們的 polls 應用現在就有一個小 bug 需要被修復：我們的要求是如果 Question 是在一天之內發布的， Question.was_published_recently() 方法將會返回 True ，然而現在這個方法在 Question 的 pub_date 欄位比當前時間還晚時也會返回 True（這是個 Bug）。
用djadmin:`shell`命令確認一下這個方法的日期bug
python manage.py shell>>> import datetime>>> from django.utils import timezone>>> from polls.models import Question>>> # create a Question instance with pub_date 30 days in the future>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))>>> # was it published recently?>>> future_question.was_published_recently()True因為將來發生的是肯定不是最近發生的，所以代碼明顯是錯誤的。
創建一個測試來暴露這個 bug我們剛剛在 shell 裡做的測試也就是自動化測試應該做的工作。所以我們來把它改寫成自動化的吧。
按照慣例，Django 應用的測試應該寫在應用的 tests.py 文件裡。測試系統會自動的在所有以 tests 開頭的文件裡尋找並執行測試代碼。
將下面的代碼寫入 polls 應用裡的 tests.py 文件內：
# polls/tests.pyimport datetime
from django.test import TestCasefrom django.utils import timezone
from .models import Question
class QuestionModelTests(TestCase):
def test_was_published_recently_with_future_question(self): """ was_published_recently() returns False for questions whose pub_date is in the future. """ time = timezone.now() + datetime.timedelta(days=30) future_question = Question(pub_date=time) self.assertIs(future_question.was_published_recently(), False)我們創建了一個 django.test.TestCase 的子類，並添加了一個方法，此方法創建一個 pub_date 時未來某天的 Question 實例。然後檢查它的 was_published_recently() 方法的返回值——它 應該 是 False。
運行測試在終端中，我們通過輸入以下代碼運行測試:
python manage.py test polls你將會看到運行結果:
Creating test database for alias 'default'...System check identified no issues (0 silenced).F======================================================================FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)Traceback (most recent call last): File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question self.assertIs(future_question.was_published_recently(), False)AssertionError: True is not False
Ran 1 test in 0.001s
FAILED (failures=1)Destroying test database for alias 'default'...發生了什麼呢？以下是自動化測試的運行過程：
python manage.py test polls 將會尋找 polls 應用裡的測試代碼
它找到了 django.test.TestCase 的一個子類
它創建一個特殊的資料庫供測試使用
它在類中尋找測試方法——以 test 開頭的方法。
在 test_was_published_recently_with_future_question 方法中，它創建了一個 pub_date 值為 30 天后的 Question 實例。
接著使用 assertls() 方法，發現 was_published_recently() 返回了 True，而我們期望它返回 False。
測試系統通知我們哪些測試樣例失敗了，和造成測試失敗的代碼所在的行號。
修復這個 bug我們早已知道，當 pub_date 為未來某天時， Question.was_published_recently() 應該返回 False。我們修改 models.py 裡的方法，讓它只在日期是過去式的時候才返回 True：
# polls/models.pydef was_published_recently(self): now = timezone.now() return now - datetime.timedelta(days=1) <= self.pub_date <= now然後重新運行測試:
Creating test database for alias 'default'...System check identified no issues (0 silenced)..Ran 1 test in 0.001s
OKDestroying test database for alias 'default'...發現 bug 後，我們編寫了能夠暴露這個 bug 的自動化測試。在修復 bug 之後，我們的代碼順利的通過了測試。
將來，我們的應用可能會出現其他的問題，但是我們可以肯定的是，一定不會再次出現這個 bug，因為只要簡單的運行一遍測試，就會立刻收到警告。我們可以認為應用的這一小部分代碼永遠是安全的。
更全面的測試我們已經搞定一小部分了，現在可以考慮全面的測試 was_published_recently() 這個方法以確定它的安全性，然後就可以把這個方法穩定下來了。事實上，在修復一個 bug 時不小心引入另一個 bug 會是非常令人尷尬的。
我們在上次寫的類裡再增加兩個測試，來更全面的測試這個方法：
# polls/tests.pydef test_was_published_recently_with_old_question(self): """ was_published_recently() returns False for questions whose pub_date is older than 1 day. """ time = timezone.now() - datetime.timedelta(days=1, seconds=1) old_question = Question(pub_date=time) self.assertIs(old_question.was_published_recently(), False)
def test_was_published_recently_with_recent_question(self): """ was_published_recently() returns True for questions whose pub_date is within the last day. """ time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59) recent_question = Question(pub_date=time) self.assertIs(recent_question.was_published_recently(), True)現在，我們有三個測試來確保 Question.was_published_recently() 方法對於過去，最近，和將來的三種情況都返回正確的值。
再次申明，儘管 polls 現在是個非常簡單的應用，但是無論它以後成長到多麼複雜，要和其他代碼進行怎樣的交互，我們都能保證進行過測試的那些方法的行為永遠是符合預期的。
4.測試視圖我們的投票應用對所有問題都一視同仁：它將會發布所有的問題，也包括那些 pub_date 欄位值是未來的問題。我們應該改善這一點。如果 pub_date 設置為未來某天，這應該被解釋為這個問題將在所填寫的時間點才被發布，而在之前是不可見的。
針對視圖的測試為了修復上述 bug ，我們這次先編寫測試，然後再去改代碼。事實上，這是一個簡單的「測試驅動」開發模式的實例，但其實這兩者的順序不太重要。
在我們的第一個測試中，我們關注代碼的內部行為。我們通過模擬用戶使用瀏覽器訪問被測試的應用來檢查代碼行為是否符合預期。
在我們動手之前，先看看需要用到的工具們。
Django 測試工具之 ClientDjango 提供了一個供測試使用的 Client 來模擬用戶和視圖層代碼的交互。我們能在 tests.py 甚至是 shell 中使用它。
我們依照慣例從 shell 開始，首先我們要做一些在 tests.py 裡不是必須的準備工作。第一步是在 shell 中配置測試環境:
python manage.py shell>>> from django.test.utils import setup_test_environment>>> setup_test_environment()setup_test_environment() 提供了一個模板渲染器，允許我們為 responses 添加一些額外的屬性，例如 response.context，未安裝此 app 無法使用此功能。注意，這個方法並 不會 配置測試資料庫，所以接下來的代碼將會在當前存在的資料庫上運行，輸出的內容可能由於資料庫內容的不同而不同。如果你的 settings.py 中關於 TIME_ZONE 的設置不對，你可能無法獲取到期望的結果。如果你之前忘了設置，在繼續之前檢查一下。
然後我們需要導入 django.test.TestCase 類（在後續 tests.py 的實例中我們將會使用 django.test.TestCase 類，這個類裡包含了自己的 client 實例，所以不需要這一步）:
>>> from django.test import Client>>> # create an instance of the client for our use>>> client = Client()搞定了之後，我們可以要求 client 為我們工作了:
>>> # get a response from '/'>>> response = client.get('/')Not Found: />>> # we should expect a 404 from that address; if you instead see an>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably>>> # omitted the setup_test_environment() call described earlier.>>> response.status_code404>>> # on the other hand we should expect to find something at '/polls/'>>> # we'll use 'reverse()' rather than a hardcoded URL>>> from django.urls import reverse>>> response = client.get(reverse('polls:index'))>>> response.status_code200>>> response.contentb'\n <ul>\n \n <li><a href="/polls/1/">What's up?</a></li>\n \n </ul>\n\n'>>> response.context['latest_question_list']<QuerySet [<Question: What's up?>]>改善視圖代碼現在的投票列表會顯示將來的投票（ pub_date 值是未來的某天)。我們來修復這個問題。
在 教程的第 4 部分 裡，我們介紹了基於 ListView 的視圖類：
# polls/views.pyclass IndexView(generic.ListView): template_name = 'polls/index.html' context_object_name = 'latest_question_list'
def get_queryset(self): """Return the last five published questions.""" return Question.objects.order_by('-pub_date')[:5]我們需要改進 get_queryset() 方法，讓他它能通過將 Question 的 pub_data 屬性與 timezone.now() 相比較來判斷是否應該顯示此 Question。首先我們需要一行 import 語句：
# polls/views.pyfrom django.utils import timezone然後我們把 get_queryset 方法改寫成下面這樣：
# polls/views.pydef get_queryset(self): """ Return the last five published questions (not including those set to be published in the future). """ return Question.objects.filter( pub_date__lte=timezone.now() ).order_by('-pub_date')[:5]Question.objects.filter(pub_date__lte=timezone.now()) returns a queryset containing Questions whose pub_date is less than or equal to - that is, earlier than or equal to - timezone.now.
測試新視圖啟動伺服器、在瀏覽器中載入站點、創建一些發布時間在過去和將來的 Questions ，然後檢驗只有已經發布的 Questions 會展示出來，現在你可以對自己感到滿意了。你不想每次修改可能與這相關的代碼時都重複這樣做 —— 所以讓我們基於以上 shell 會話中的內容，再編寫一個測試。
將下面的代碼添加到 polls/tests.py ：
# polls/tests.pyfrom django.urls import reverse然後我們寫一個公用的快捷函數用於創建投票問題，再為視圖創建一個測試類：
# polls/tests.pydef create_question(question_text, days): """ Create a question with the given `question_text` and published the given number of `days` offset to now (negative for questions published in the past, positive for questions that have yet to be published). """ time = timezone.now() + datetime.timedelta(days=days) return Question.objects.create(question_text=question_text, pub_date=time)
class QuestionIndexViewTests(TestCase): def test_no_questions(self): """ If no questions exist, an appropriate message is displayed. """ response = self.client.get(reverse('polls:index')) self.assertEqual(response.status_code, 200) self.assertContains(response, "No polls are available.") self.assertQuerysetEqual(response.context['latest_question_list'], [])
def test_past_question(self): """ Questions with a pub_date in the past are displayed on the index page. """ create_question(question_text="Past question.", days=-30) response = self.client.get(reverse('polls:index')) self.assertQuerysetEqual( response.context['latest_question_list'], ['<Question: Past question.>'] )
def test_future_question(self): """ Questions with a pub_date in the future aren't displayed on the index page. """ create_question(question_text="Future question.", days=30) response = self.client.get(reverse('polls:index')) self.assertContains(response, "No polls are available.") self.assertQuerysetEqual(response.context['latest_question_list'], [])
def test_future_question_and_past_question(self): """ Even if both past and future questions exist, only past questions are displayed. """ create_question(question_text="Past question.", days=-30) create_question(question_text="Future question.", days=30) response = self.client.get(reverse('polls:index')) self.assertQuerysetEqual( response.context['latest_question_list'], ['<Question: Past question.>'] )
def test_two_past_questions(self): """ The questions index page may display multiple questions. """ create_question(question_text="Past question 1.", days=-30) create_question(question_text="Past question 2.", days=-5) response = self.client.get(reverse('polls:index')) self.assertQuerysetEqual( response.context['latest_question_list'], ['<Question: Past question 2.>', '<Question: Past question 1.>'] )讓我們更詳細地看下以上這些內容。
首先是一個快捷函數 create_question，它封裝了創建投票的流程，減少了重複代碼。
test_no_questions 方法裡沒有創建任何投票，它檢查返回的網頁上有沒有 "No polls are available." 這段消息和 latest_question_list 是否為空。注意到 django.test.TestCase 類提供了一些額外的 assertion 方法，在這個例子中，我們使用了 assertContains() 和 assertQuerysetEqual() 。
在 test_past_question 方法中，我們創建了一個投票並檢查它是否出現在列表中。
在 test_future_question 中，我們創建 pub_date 在未來某天的投票。資料庫會在每次調用測試方法前被重置，所以第一個投票已經沒了，所以主頁中應該沒有任何投票。
剩下的那些也都差不多。實際上，測試就是假裝一些管理員的輸入，然後通過用戶端的表現是否符合預期來判斷新加入的改變是否破壞了原有的系統狀態。
測試 DetailView我們的工作似乎已經很完美了？不，還有一個問題：就算在發布日期時未來的那些投票不會在目錄頁 index 裡出現，但是如果用戶知道或者猜到正確的 URL ，還是可以訪問到它們。所以我們得在 DetailView 裡增加一些約束：
# polls/views.pyclass DetailView(generic.DetailView): ... def get_queryset(self): """ Excludes any questions that aren't published yet. """ return Question.objects.filter(pub_date__lte=timezone.now())當然，我們將增加一些測試來檢驗 pub_date 在過去的 Question 可以顯示出來，而 pub_date 在未來的不可以：
# polls/tests.pyclass QuestionDetailViewTests(TestCase): def test_future_question(self): """ The detail view of a question with a pub_date in the future returns a 404 not found. """ future_question = create_question(question_text='Future question.', days=5) url = reverse('polls:detail', args=(future_question.id,)) response = self.client.get(url) self.assertEqual(response.status_code, 404)
def test_past_question(self): """ The detail view of a question with a pub_date in the past displays the question's text. """ past_question = create_question(question_text='Past Question.', days=-5) url = reverse('polls:detail', args=(past_question.id,)) response = self.client.get(url) self.assertContains(response, past_question.question_text)更多的測試思路我們應該給 ResultsView 也增加一個類似的 get_queryset 方法，並且為它創建測試。這和我們之前幹的差不多，事實上，基本就是重複一遍。
我們還可以從各個方面改進投票應用，但是測試會一直伴隨我們。比方說，在目錄頁上顯示一個沒有選項 Choices 的投票問題就沒什麼意義。我們可以檢查並排除這樣的投票題。測試可以創建一個沒有選項的投票，然後檢查它是否被顯示在目錄上。當然也要創建一個有選項的投票，然後確認它確實被顯示了。
恩，也許你想讓管理員能在目錄上看見未被發布的那些投票，但是普通用戶看不到。不管怎麼說，如果你想要增加一個新功能，那麼同時一定要為它編寫測試。不過你是先寫代碼還是先寫測試那就隨你了。
在未來的某個時刻，你一定會去查看測試代碼，然後開始懷疑：「這麼多的測試不會使代碼越來越複雜嗎？」。別著急，我們馬上就會談到這一點。
5.當需要測試的時候，測試用例越多越好貌似我們的測試多的快要失去控制了。按照這樣發展下去，測試代碼就要變得比應用的實際代碼還要多了。而且測試代碼大多都是重複且不優雅的，特別是在和業務代碼比起來的時候，這種感覺更加明顯。
但是這沒關係！ 就讓測試代碼繼續肆意增長吧。大部分情況下，你寫完一個測試之後就可以忘掉它了。在你繼續開發的過程中，它會一直默默無聞地為你做貢獻的。
但有時測試也需要更新。想像一下如果我們修改了視圖，只顯示有選項的那些投票，那麼只前寫的很多測試就都會失敗。但這也明確地告訴了我們哪些測試需要被更新，所以測試也會測試自己。
最壞的情況是，當你繼續開發的時候，發現之前的一些測試現在看來是多餘的。但是這也不是什麼問題，多做些測試也 不錯。
如果你對測試有個整體規劃，那麼它們就幾乎不會變得混亂。下面有幾條好的建議：
6.深入代碼測試在本教程中，我們僅僅是了解了測試的基礎知識。你能做的還有很多，而且世界上有很多有用的工具來幫你完成這些有意義的事。
舉個例子，在上述的測試中，我們已經從代碼邏輯和視圖響應的角度檢查了應用的輸出，現在你可以從一個更加 "in-browser" 的角度來檢查最終渲染出的 HTML 是否符合預期，使用 Selenium 可以很輕鬆的完成這件事。這個工具不僅可以測試 Django 框架裡的代碼，還可以檢查其他部分，比如說你的 JavaScript。它假裝成是一個正在和你站點進行交互的瀏覽器，就好像有個真人在訪問網站一樣！Django 它提供了 LiveServerTestCase 來和 Selenium 這樣的工具進行交互。
如果你在開發一個很複雜的應用的話，你也許想在每次提交代碼時自動運行測試，也就是我們所說的持續集成 continuous integration ，這樣就能實現質量控制的自動化，起碼是部分自動化。
一個找出代碼中未被測試部分的方法是檢查代碼覆蓋率。它有助於找出代碼中的薄弱部分和無用部分。如果你無法測試一段代碼，通常說明這段代碼需要被重構或者刪除。想知道代碼覆蓋率和無用代碼的詳細信息，查看文檔 Integration with coverage.py 獲取詳細信息。
文檔 Django 中的測試 裡有關於測試的更多信息。
7.接下來要做什麼？
如果你想深入了解測試，就去看 Django 中的測試 。
當你已經比較熟悉測試 Django 視圖的方法後，就可以繼續閱讀 教程第 6 部分 ，學習靜態文件管理的相關知識。
請留下你指尖的溫度
讓太陽擁抱你
微信ID:haopython