iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 21
0
Modern Web

來個Django Web介面測試吧系列 第 21

來個Django Web介面測試吧:Day21-Django 重構設計(5)

前面已經重構了一個線上投票應用,在這一部分,將創建一些自動化測試。

自動化測試簡介

自動化測試是什麼?

測試,是用來檢查代碼正確性的一些簡單的程式。

測試在不同的層次中都存在。有些測試只關註某個很小的細節(例如:某個模型的某個方法的返回值是否滿足預期?),而另一些測試可能檢查對某個軟體的一系列操作(例如:某一用戶輸入序列是否造成了預期的結果?)。

真正不同的地方在於,自動化 測試是由某個系統幫你自動完成的。當創建好一系列測試,每次修改應用代碼後,就可以自動檢查出修改後的代碼是否如曾經預期,且正常地工作。而不花費大量時間來進行手動測試。

為什麼需要寫測試

但是,為什麼需要測試呢?又為什麼是現在呢?

也許某些人可能會覺得學 Python/Django 已經很滿足了,再學一些新東西的話看起來有點負擔過重並且沒什麼必要。畢竟,前面的投票應用看起來已經完美工作了。寫一些自動測試並不能讓它工作的更好。如果寫一個投票應用是唯一想用 Django 完成的工作,那確實沒必要學寫測試。但是如果還想寫更複雜的專案,現在就是學習測試寫法的最好時機了。

測試將節約你的時間

在某種程度上,能夠「判斷出代碼是否正常工作」的測試,就稱得上是個令人滿意的了。在更複雜的應用程式中,組件之間可能會有數十個複雜的交互。

在更加複雜的應用中,各種組件之間的交互可能會及其的複雜。改變其中某一組件的行為,也有可能會造成意想不到的結果。判斷「代碼是否正常工作」意味著你需要用大量的數據來完整的測試全部代碼的功能,以確保你的小修改沒有對應用整體造成破壞——這太費時間了。

尤其是當發現自動化測試能在幾秒鐘之內能完成這件事時,就更會覺得手動測試實在是太浪費時間了。當某人寫出錯誤的代碼時,自動化測試還能幫助定位錯誤代碼的位置。

有時候會覺得,和富有創造性和生產力的業務代碼比起來,編寫枯燥的測試代碼實在是太無聊了,特別是當知道自己的代碼完全沒有問題的時候。

然而,編寫測試還是要比花費幾個小時手動測試自己的應用,或者為了找到某個小錯誤而胡亂翻看代碼要有意義的多。

測試不僅能發現錯誤,而且能預防錯誤

「測試是開發的對立面」,這種思想是不對的。

如果沒有測試,整個應用的行為意圖會變得更加的不清晰。甚至當你在看自己寫的代碼時也是這樣,有時候你需要仔細研讀一段代碼才能搞清楚它有什麼用。

而測試的出現改變了這種情況。測試就好像是從內部仔細檢查你的代碼,當有些地方出錯時,這些地方將會變得很顯眼——就算你自己沒有意識到那裡寫錯了。

測試使你的代碼更有吸引力

你也許遇到過這種情況:你編寫了一個絕贊的軟體,但是其他開發者看都不看它一眼,因為它缺少測試。沒有測試的代碼不值得信任。 Django 最初開發者之一的 Jacob Kaplan-Moss 說過:“專案規劃時沒有包含測試是不科學的。”

其他的開發者希望在正式使用你的代碼前看到它通過了測試,這是你需要寫測試的另一個重要原因。

測試有利於團隊協作

前面的幾點都是從單人開發的角度來說的。複雜的應用可能由團隊維護。測試的存在保證了協作者不會不小心破壞了了你的代碼(也保證你不會不小心弄壞他們的)。如果你想作為一個 Django 程式員謀生的話,你必須擅長編寫測試!

基礎測試策略

有好幾種不同的方法可以寫測試。

一些開發者遵循 "測試驅動" 的開發原則,他們在寫代碼之前先寫測試。這種方法看起來有點反直覺,但事實上,這和大多數人日常的做法是相吻合的。我們會先描述一個問題,然後寫代碼來解決它。「測試驅動」的開發方法只是將問題的描述抽象為了 Python 的測試樣例。

更普遍的情況是,一個剛接觸自動化測試的新手更傾向於先寫代碼,然後再寫測試。雖然提前寫測試可能更好,但是晚點寫起碼也比沒有強。

有時候很難決定從哪裡開始下手寫測試。如果你才寫了幾千行 Python 代碼,選擇從哪裡開始寫測試確實不怎麼簡單。如果是這種情況,那麼在你下次修改代碼(比如加新功能,或者修復 Bug)之前寫個測試是比較合理且有效的。

所以,我們現在就開始寫吧。


上一篇
來個Django Web介面測試吧:Day20-Django 重構設計(4)
下一篇
來個Django Web介面測試吧:Day22-Django 重構設計(6)
系列文
來個Django Web介面測試吧30

尚未有邦友留言

立即登入留言