我是單元測試新手。假設我正在構建一個Web應用程序。我如何知道要測試什麼？你看到的所有例子都是某種基本的求和函數，它實際上沒有真正的價值，或者至少我從來沒有寫過一個函數來添加輸入，然後返回！你用單元測試測試什麼？
所以，我的問題......在Web應用程序上，需要測試什麼類型的東西？
我知道這是一個廣泛的問題，但任何事情都會有所幫助。我會對鏈接或任何能夠提供真實生活實例的東西感興趣，而不是那些沒有任何真實生活用法的概念實例。
看看你的代碼，尤其是你有複雜的邏輯與循環，條件等位，並問自己：我怎麼知道這是否工作？
如果您需要更改複雜邏輯以考慮其他角落案例，那麼您如何知道您所引入的更改不會破壞現有案例？這正是單元測試旨在解決的問題。
因此，要回答您關於它如何應用於Web應用程序的問題：假設您有一些代碼根據瀏覽器對頁面進行不同的佈局。你的一個客戶拒絕從IE6升級，並堅持認爲你支持。因此，您通過模擬IE6中的連接字符串並檢查佈局是否符合您的期望，從而單元測試佈局代碼。
一位顧客告訴你他們已經發現了一個安全漏洞，使用特定的cookie會給你管理員訪問權限。你怎麼知道你已經修復了錯誤，並且它不再發生？爲它創建一個單元測試，並且每天運行單元測試，以便在失敗時得到預警。
您發現一個錯誤，其名稱中帶有重音的用戶在數據庫中遭到損壞。從數據庫層抽象出網絡表單輸入並添加單元測試，以確保（例如）UTF8編碼數據正確存儲在數據庫中並可被檢索。
你明白了。任何地方，部分流程都有明確的輸入和輸出，非常適合單元測試。任何不是理想的重構，直到它被明確定義。看看諸如WebUnit，HTMLUnit，XMLUnit，CSSUnit等項目。
測試的第一部分是編寫可測試的應用程序。從UI中分離出儘可能多的功能。重構成更小的方法。瞭解依賴注入，並嘗試使用它來創建方法，這些方法可以採用簡單的可拋棄輸入來生成已知（併爲此可測試）的結果。看看嘲笑的工具。
基礎架構和數據層代碼最容易測試。
看看行爲驅動的測試以及測試驅動的設計。對於我的錢來說，行爲測試比單純的單元測試要好;您可以遵循用例，以便測試與預期的使用模式相匹配。
對於Web應用程序，您需要做的測試類型稍有不同。單元測試是測試程序的特定組件的測試。對於Web應用程序，您需要測試表單是否接受正確的輸入，所有鏈接指向正確的位置，它可以處理意外的輸入等。如果我是你，我會看看Selenium，我已經在測試多個站點時廣泛使用它：Selenium HQ
我沒有測試網絡應用程序的經驗，但通常會說：您可以單元測試程序中最小的「塊」。這意味着您可以在單獨的基礎上測試每個功能。大規模的任何事情都會成爲一種綜合測試。
當然，會有這麼簡單的方法，它不值得您花時間爲他們編寫測試，但總體目標是測試儘可能多的代碼。
單元測試意味着測試任何工作單元，最小的工作單元是方法和函數。單元測試的藝術是定義一個函數的測試，這個函數不能通過檢查來檢查，單元測試的目標是測試方法的每個可能的功能需求。
考慮，比如你有一個登錄功能，那麼就可能是你可以爲失敗編寫以下測試： 1.該功能對空的用戶名和密碼 2.未能在正確的用戶名是否該函數失敗，但錯誤的密碼 3.請問功能上正確的密碼，但錯誤的用戶名
的你也寫測試失敗，該功能會通過： 1.關於是否正確的用戶名和密碼的功能通
這只是一個基本的例子，但這是單元測試的嘗試實現，測試可能在開發過程中被忽略的事物。
然後還有一個純粹的方法，開發人員首先應該編寫測試，然後通過這些測試（又名測試驅動開發）的代碼。
資源： http://devzone.zend.com/article/2772 http://www.ibm.com/developerworks/library/j-mocktest.html
如果你是新來的TDD，我可以提出一個快速訪問到BDD的世界？我的經驗是，該語言確實可以幫助人們更迅速地獲取TDD。特別是，我點你在本文中，其中單北暗示「要考什麼」：透明度
http://blog.dannorth.net/introducing-bdd/
注：我可能是大量參與了BDD運動。
關於在Web應用程序中進行單元測試的類，我會考慮從控制器，域對象（如果它們具有複雜行爲）以及任何名爲「service」，「manager」，「helper」或「util」 。也請嘗試重命名這樣的類，以便它們不那麼通用並且實際地說出它們的作用。稱爲「計算器」或「轉換器」的類也是很好的候選者，您可能會在同一個包/文件夾中找到更多類。
有一對夫婦的好書，可以幫助你太：
祝你好運 「修改代碼的工作」 ！
爲偉大的鏈接+1！ – Icode4food 2010-08-23 16:29:52
經驗法則是，如果它不值得測試，則不值得編寫。
但是，有些事情是非常難以測試的，所以您需要對測試內容做一些成本效益分析。如果您最初的目標是70％的代碼覆蓋率，那麼您將走在正確的軌道上。
如果您開始說「如何測試我的網絡應用程序？」那就是一次咬掉很多，單元測試很難讓人看到任何好處。我從單獨的小塊開始進行單元測試，然後編寫測試優先庫，然後才構建可測試的整個應用程序。
通常，一個web應用程序具有一個域模型，它具有數據訪問對象，用於對數據庫執行查詢並返回域對象，具有調用數據訪問對象的服務，並且具有接受http請求並調用服務。
控制器的測試將檢查他們是否使用正確的參數調用正確的服務方法。服務對象可以在測試設置期間被模擬注入。
服務測試將檢查他們調用正確的數據訪問對象並執行他們需要執行的任何邏輯。數據訪問對象可以在測試設置期間被模擬注入。
數據訪問對象的測試將通過檢查數據庫之前和之後的內容來檢查它們是否執行正確的數據庫操作（查詢或更新或其他）。對於dao測試，您需要一個數據庫和一個像DBUnit這樣的工具來在測試之前預先填充它。此外，您的域對象的getter和setter將通過此測試得到行使，因此您不需要爲它們單獨測試。
域模型的測試將檢查您編碼的域邏輯是否有效（有時您可能沒有）。如果您設計的域模型不與數據庫耦合，那麼您放入域模型的邏輯就越好，因爲它很容易測試。這些測試你不應該需要任何模擬。
+1爲真正的好鏈接。我喜歡devzone.zend.com文章最好。 – Icode4food 2010-08-23 16:30:27