亚洲精品无粉嫩AV,丝瓜草莓秋葵污WWW旧版安卓

為什么要測試，測試是如何令人更快樂的？（二）

來源：教育聯(lián)展網｜發(fā)布時間：｜編輯：佚名

來源：51Testing軟件測試網

知道測試什么是關鍵
知道測試什么沒有聽上去得那么容易，并且有很大一部分是由經驗所決定的。許多測試測試得太多。知道要測試什么涉及到要了解什么重要，什么不重要，而要知道這些并不是一件隨隨便便就能做到的事情。這里有一個技巧，但：
“盡可能采用**高級別的測試，以便于在實現上覆蓋范圍和靈活性?！?/span>——Brian Lonsdorf，《JavaScript. Air 004》
所以，基本上：
不要測試內部的東西，這只會成為你的阻礙。如果你真的覺得你應該測試內部的東西，那么你**分離成一個新的模塊，使之成為外部的東西。
不要測試過于指定，或處理它們不必和不應該知道的東西。
不要只是為了獲得 100％的覆蓋率而去寫測試。如果有人告訴你應該保持 100％的覆蓋率，那么不要廢話，揍他。
請記住，測試應該從模塊外部的角度開始由外到內。需要注意的是完全覆蓋的測試還是有可能的，即代碼的所有分支應該都可以實現。如果沒有，那么它們基本上是死碼，不是嗎？除非你需要更好地理解它們是如何工作的，否則就不要測試內部的東西。
想想當一段時間以后，代碼重構的時候，會發(fā)生什么。實現應該允許在測試不失敗的情況下被更改。為什么？因為如果將來的程序員需要改測試的話，那么基本上是重寫，而不是重構。并且重寫并不安全。對于重構內部應該沒有新的測試。
在測試時要務實。測試是項目以及創(chuàng)造價值的一部分，什么都拿來測試沒有任何意義，就像實現所有按鈕沒有意義一樣。記住文檔方面。如果測試涉及許多實施細節(jié)，那么我們就會失去模塊的重點。我們就會失去文檔的價值。
至于文檔，測試你的領域假設。這些都是你工作的問題域的代碼解釋，這些問題域往往是一些程序員不擅長的地方。用代碼的形式文檔化這些假設解決了兩個問題：自我文檔化假設，并證明它們能夠如解釋那樣有效工作。
當你發(fā)現 bug 的時候，編寫測試。不要只是修復它。去寫測試，確保它既是紅的，又對齊 bug 所沒有意識到的期望。修復 bug，使其呈現綠色。保存。
代碼覆蓋作為一個具體的數字被高估了，但作為一種工具它還是很有用的。不要為了覆蓋范圍而力求覆蓋。請記住，覆蓋范圍只能告訴你測試在代碼行運行什么，而不會告訴你測試將運行什么組合。不過，這可以成為事情是否朝著正確方向前進的一個很好的風向標。如果重構導致更糟的代碼覆蓋范圍，那么就應該響起警鈴，尤其是如果它是重構的話。不要只是為了增加覆蓋數值就讓自己去編寫測試。經過充分測試和編寫良好的代碼的覆蓋數值更大。
編寫測試的觸發(fā)器是當你的代碼片段有新的行為的時候。測試應該盯牢這種行為，但不要矯枉過正。
測試庫可能比測試終端應用程序更容易，更為重要。畢竟，庫會被多個應用程序使用。
如何編寫特別棒的測試
知道如何寫出好的測試是關鍵，因為很容易寫得不好。事實是，和其他所有一切一樣，它需要實踐。不過，這里有一些小貼士。
好的測試往往是簡單的。它不會嘗試一氣呵成面面俱到。它的名字反映了它要的目的，并且名稱應該精簡成一句話。例如，名稱不應該是“it works”，而是“it returns 0 for negative values”。
確保測試不要過于指定。過于指定的測試涉及到太多內部東西，并且不允許重構。
單元測試運行代碼時會隔離其他測試，不一定是其他代碼的測試。它將代碼帶出它的上下文，并創(chuàng)建其中一個方面的人工上下文，以便于進行調查。然而，這并不意味著單元測試必須得在隔離其他所有代碼的情況下運行，盡管這通常被認為是“純單元測試”。所有一切都沒有必要 mock 和 stub，因為只會導致更復雜的設置，更低的覆蓋率和更加脆弱的測試。
在有意義的地方使用 mock 和 stub。你不想對一個真正的 HTTP API 進行測試，那就 stub。如果你正在測試的東西是你自己對該對象的調用，或你想要自己的代碼歷經某個路徑，那么使用使用 mock 和 stub。
測試讀起來應該像一個小故事，遵循 AAA 體系： Arrange、Act、Assert。設置東西，做出聲明，并且斷言聲明做了它應該做的。 “小故事”方面要重視小的方面。“3A”中沒有一個應該超過 3 行代碼以上。在階段之間留一些空間會更好。應該沒有任何分支和循環(huán)，你在斷言時應該只涉及一個邏輯內容。（如果一個斷言語句就能表達自然是好，但有時你需要更多，那也沒關系。）永遠不要在測試的兩個不同的地方斷言，因為這會導致你實際測試的混亂。
測試應該只需要一些領域知識就可讀。如果不深入模塊的內部運作就很難解釋的話，那么要么你**多花一些時間在測試上，那么徹底棄之不顧。
一般情況下，不要測試依賴。對于某些項目，對一些代碼所做的假設做一些簡單的測試，可能是有意義的，但要謹慎和小心。測試庫是庫作者的工作。相反，要依靠更新日志進行升級，以及依賴于測試集成而不是庫（不用 mock 一切的一個原因）。
編寫不需要很長時間運行的低成本測試，因為要時常運行這些測試。如果你可以傳遞 --watch 參數到你的測試運行中，并且在每次有文件改變時運行它，那么這是一件好事。
**后但并非**不重要的一點是，使用你喜歡的測試框架。如果 JavaScript. 是你的菜，那么我會推薦 AVA，因為它清晰簡單，而且沒有復雜的配置。不管你選擇什么，確保測試框架能和你一起工作，并幫助你編寫測試更高效，更快捷。正如編碼一樣，如果你覺得不好玩，那么可能有什么地方出錯了。