雖然單元測試似乎對API需要具備行業實力的大型項目（例如.Net框架API的開發等）有效，但似乎可能對較小項目。什麼時候進行單元測試與手動測試
當是自動TDD方式的最佳途徑，而當它可能是最好只使用手動測試技術，登錄錯誤，分流，解決這些問題，等等
另一個問題 - 當我是微軟的一名測試人員，向我們強調，讓開發人員和測試人員成爲不同的人是有價值的，而這兩個小組之間的緊張關係最終可以幫助創建出色的產品。 TDD能否打破這種想法並創造一種情況，即開發人員可能不適合嚴格地找到自己的錯誤？它可能是自動化的，但似乎有很多方法來編寫測試，而且給定的一組測試是否能「證明」質量是可以接受的，這是值得懷疑的。
TDD的有效性與項目規模無關。即使是最小的編程練習，我也會練習the three laws of TDD。測試不需要太多時間來編寫，而且節省了大量的調試時間。他們還允許我重構代碼，而不用擔心會破壞任何東西。
TDD是一個類似於會計師實行雙記賬的學科的學科。它可以防止錯誤。會計師將每次交易進行兩次，一次作爲信用，一次作爲借方。如果沒有發生簡單的錯誤，那麼資產負債表將總計爲零。該零是一個簡單的抽查，防止高管進入監獄。同樣的道理，程序員在編寫代碼之前先編寫單元測試，作爲一個簡單的抽查。實際上，他們將每一位代碼寫兩次;一次作爲測試，一次作爲生產代碼。如果測試通過，則兩位代碼是一致的。這兩種做法都不能防止更大更復雜的錯誤，但這兩種做法都是有價值的。
TDD的實踐並不是真正的測試技術，而是一種開發實踐。 TDD中的「測試」一詞或多或少是巧合。因此，TDD不是好的測試實踐的替代品，也不是好的QA測試人員。事實上，讓有經驗的測試人員編寫代碼（及其單元測試）的程序員獨立（並且經常提前）編寫QA測試計劃是一個非常好的主意。
這是我的偏好（不愧是我的激情），這些獨立的QA測試也使用的工具，像FitNesse，Selenium，或Watir自動化。這些測試應該容易被商業人士閱讀，易於執行並且完全毫不含糊。您應該能夠在一會兒的時間內運行它們，通常每天多次運行它們。
每個系統也需要手動測試。但是，手動測試不應該是死記硬背的。可以編寫腳本的測試應該是自動化的。當需要人爲判斷時，你只想讓人類進入循環。因此人類應該做exploratory testing，而不是盲目地遵循測試計劃。
因此，單元測試與手動測試何時進行比較的簡短答案是沒有「對比」。您應該爲自己編寫的絕大多數代碼編寫自動化單元測試第一個。您應該有由測試人員編寫的自動QA驗收測試。而且你還應該練習戰略探索性手動測試。
很高興在這裏見到你*親愛的叔叔鮑勃* ... + 1爲你獨特的例子...在這裏像雙記帳。謝謝。 – Snesh 2014-12-19 10:26:21
只要可行，TDD是最好的方法。 TDD測試是自動的，可通過代碼覆蓋進行量化，以及確保代碼質量的可靠方法。
手動測試需要大量的時間（與TDD相比）並且存在人爲錯誤。
沒有什麼說TDD意味着只有開發者測試。開發人員應該負責編碼測試框架的一個百分比。 QA應負責更大的部分。開發人員以他們想測試它們的方式測試API。 QA以我真正無法想到的方式測試API，並且做些看起來很瘋狂但實際上是由客戶完成的事情。
單元測試並不意味着取代功能/組件測試。單元測試真的很專注，所以他們不會碰到數據庫，外部服務等等。集成測試可以做到這一點，但你可以讓他們真正專注。底線是，在具體問題上，答案是他們不會取代那些手動測試。 現在，自動功能測試+自動化組件測試當然可以取代手動測試。這將取決於很多項目和實際執行這些項目的方法。
更新1：請注意，如果開發人員正在創建自動功能測試，您仍然希望檢查那些具有適當的覆蓋範圍，並根據需要進行補充。一些開發人員創建的自動化與他們的「單位」測試框架的功能測試，因爲他們還要做冒煙測試無論是單元測試，它確實有助於那些具有自動:)
更新2：單元測試ISN」對於一個小項目而言過於誇張，也不能自動化煙霧測試或使用TDD。什麼是過度殺傷是讓團隊第一次爲這個小項目做這些事情。做任何這些都有相關的學習曲線（特別是單元測試或TDD），並不總是會在第一時間完成。您也希望有人蔘與了一段時間，幫助避免陷阱並克服一些開始時不明顯的編碼挑戰。問題在於團隊擁有這些技能並不常見。
我要說的是，單元測試是一個程序員的援助來回答這個問題：
這段代碼我想這 呢？
這是一個他們需要問自己很多問題。程序員喜歡在任何他們能做的事情上自動執行任何事情。
單獨的測試團隊需要回答一個不同的問題： -
此係統是否做什麼，我（和最終用戶）希望它 辦？還是讓我驚訝？
有一整套龐大的錯誤與程序員或設計師有關於什麼是正確的單元測試永遠不會被拾取的想法有關。
這就是我們在安全關鍵軟件中的工作方式。程序員證明他們的代碼在所有州/分支中都是安全的。測試人員（系統級別）獨立測試他們對高級功能要求的解釋。編寫完全不符合客戶要求的完美代碼很容易。 – MattP 2015-08-11 23:22:04
單元測試只能走得太遠（所有其他類型的測試都可以）。我將測試視爲一種「篩」過程。每一種不同類型的測試都像是你在開發過程中放置的篩子。出來的東西（希望）主要是用於軟件產品的功能，但它也包含錯誤。這些錯誤有很多不同的形狀和大小。
一些錯誤很容易找到，因爲它們很大或基本上被任何類型的篩子捕獲。另一方面，有些蟲子光滑有光澤，或者兩側沒有很多鉤子，所以它們很容易滑入一種篩子。不同類型的篩可能具有不同的形狀或大小的孔，以便能夠捕捉不同類型的錯誤。你有更多的篩子，你會發現更多的錯誤。
很明顯，你的篩選越多，功能的穿透速度越慢，所以你會想嘗試找到一個快樂的媒介，而不是花太多時間來測試你永遠不會發布任何軟件。
自動化單元測試最好的一點（IMO）是，當你改變（改進，重構）現有的代碼時，很容易測試你沒有破壞它。一次又一次地手動測試一切將是乏味的。
每個應用程序都經過測試。
某些應用程序會以我的代碼編譯的形式進行測試，並且代碼是否顯示爲函數。
某些應用程序已通過測試單元測試。一些開發人員對單元測試，TDD和代碼覆蓋率有過錯。像所有事情一樣，太多往往不是壞事。
某些應用程序足以幸運地通過QA團隊進行測試。一些QA團隊可以自動執行測試，其他人則編寫測試用例並手動測試。
Michael Feathers寫道：Working Effectively with Legacy Code寫道，測試中未包含的代碼是遺留代碼。直到您遇到了Big Ball of Mud，我認爲任何開發人員都不會真正理解好的應用程序體系結構和一套寫得很好的單元測試的好處。
讓不同的人測試是一個好主意。可以查看應用程序的人越多，所有場景就會被覆蓋的可能性就越大，包括那些你不打算髮生的情況。
TDD最近得到了不好的說唱。當我想到TDD我認爲教條式開發人員在編寫實現之前一絲不苟地編寫測試。雖然這是事實，但被忽視的是編寫測試（開始或結束後）開發人員體驗消費者的方法/課程。設計缺陷和缺點立即顯現。
我認爲大小的項目是無關緊要的。重要的是是該項目的使用壽命。項目越長，開發人員之外的開發人員就越有可能工作。單元測試是符合應用程序期望的文檔 - 各種手冊。
單元測試似乎對於大型項目非常有效，因爲大型項目的API需要具備行業實力，看起來可能像小項目上的矯枉過正。
確實，移動API的單元測試很脆弱，但單元測試對於API等較少的項目（如應用程序）也是有效的。單元測試是爲了測試一個項目所在的單元。它可以確保每個單元按預期工作。修改 - 重構 - 代碼時，這是一個真正的安全網。
就項目規模而言，確實爲小型項目編寫單元測試可能會過度。在這裏，我將小項目定義爲一個小程序，可以在幾秒鐘內手動測試，但非常簡單快速。另外一個小項目可能會增長，在這種情況下，手頭可能有單元測試的優勢。
讓開發人員和測試人員成爲不同的人是有價值的，而且這兩個羣體之間的緊張關係可以幫助創造一個偉大的產品。
無論發展過程中，單元測試並不意味着取代測試的任何其他階段，但他們在發展水平測試的補充，使開發人員可以得到非常早期的反饋，而無需等待正式版本和官方測試。通過單元測試，開發團隊可以提供適用於下游的代碼，而不是無缺陷的代碼，但代碼可以由測試團隊進行測試。總之，我真的很容易測試，或者編寫單元測試過於複雜，我不打算100％覆蓋。
你的問題似乎更多地是關於自動化測試與手動測試。單元測試是一種自動化測試的形式，但卻是一種非常具體的形式
你有關於讓單獨的測試人員和開發人員的言論是正確的。但這並不意味着開發人員不應該進行某種形式的驗證。
單元測試是開發人員快速反饋他們所做內容的一種方式。他們編寫測試以快速運行小部分代碼並驗證其正確性。它不是真正的測試，因爲你似乎使用了單詞測試，就像編譯器的語法檢查沒有測試一樣。單元測試是一種開發技術。使用這種技術編寫的代碼可能比編寫代碼時質量更高，但仍需通過質量控制。
有關測試部門的自動化測試和手動測試的問題更容易回答。只要項目變得足夠大以證明自動化測試的投入，就應該使用自動化測試。當你有很多小型的一次性測試時，你應該手動進行測試。
根據各項目研究（1），單元測試發現缺陷（平均30％）的15..50％。這不會使他們成爲你的武器庫中最糟糕的bug發現者，但也不是銀彈。有是沒有銀彈，任何好的QA策略都是由多種技巧組成。
是自動化測試更多的時候運行，因此它會更早發現缺陷和減少這些巨大的總成本 - 這是測試自動化的真正價值。
明智地投資您的資源並首先選擇低掛果。
我發現自動化測試最容易編寫和維護小代碼單元 - 獨立的函數和類。最終用戶功能更容易手動測試 - 一個好的測試人員會發現超出所需測試的許多古怪事物。不要把它們放在對方身上，你們都需要。
開發與測試人員開發人員是在測試自己的代碼不好是衆所周知的：原因是心理，技術和持續至少不經濟 - 測試通常比開發商便宜。但開發人員可以儘自己的一份力，並使測試更容易。 TDD使得測試成爲程序構建的一個固有部分，而不僅僅是事後的考慮，這就是TDD的真正價值。
關於測試的另一個有趣的觀點：100％的覆蓋率沒有意義。統計上，錯誤遵循80:20的規則 - 大部分錯誤都是在小部分代碼中找到的。 Some studies表明這更加尖銳 - 測試應該關注bug出現的地方。
（1）編程生產力Jones 1986 u.a.引自Code Complete，2nd。編輯。但正如其他人所說，單元測試只是測試的一部分，集成，迴歸和系統測試也可以部分自動化。
我對結果的解釋是：「許多眼睛」具有最佳的缺陷檢測能力，但只有當你有一些正式的過程才能使它們看起來真實。
研究鏈接是一個死鏈接。 – 2017-05-06 16:48:21
只是爲了澄清這是許多人似乎錯過：
TDD，在 意義上的「寫失敗的測試，編寫代碼來使測試通過，重構，重複」 通常是最有效和最有用當你寫單元測試。
你寫一個單元測試，只是圍繞你正在使用的代碼的類/函數/單元，使用模擬或存根抽象出系統的其餘部分。
「自動」測試通常是指更高級別的集成/驗收/功能測試 - 您可以在此級別的測試中執行TDD，並且它通常是嚴重用戶驅動代碼的唯一選項，但您應該瞭解這種測試更加脆弱，更難以編寫測試優先，也不能替代單元測試。
在雙方都進行QA和開發之後，我會斷言有人應該總是手動測試你的代碼。即使您使用TDD，作爲開發人員的許多事情可能無法用單元測試覆蓋，或者可能無法考慮測試。這尤其包括可用性和美學。美學包括正確的拼寫，語法和輸出格式。
活生生的例子1：
開發人員創造了我們展示我們的管理者內部網的報告。有很多公式，開發人員在代碼進入質量保證之前都進行了測試。我們證實這些公式確實產生了正確的結果。我們要求發展幾乎立即糾正的事實是，數字在紫色背景上以粉紅色顯示。
真實生活中的例子2：
我寫的代碼在我的業餘時間，使用TDD。我喜歡認爲我徹底測試它。有一天，當我有一個對話的消息對話時，我的妻子走過去，讀了一遍，並且及時地問：「這個消息應該是什麼意思？」我認爲這個消息很清楚，但是當我重讀它時，我意識到它正在討論樹控件中的父節點和子節點，並且可能對普通用戶沒有意義。我重寫了這個消息。在這種情況下，這是一個可用性問題，這個問題沒有被我自己的測試所捕獲。
我相信可以將QA /測試人員（定義測試/接受標準）的專業知識與使用開發人員擁有的API（與GUI或HTTP /消息接口相反）的TDD概念結合起來被測試的應用程序。
它仍然是有獨立的QA人員至關重要，但我們不再需要龐大的人工測試團隊與現代測試工具，如FitNesse的，硒和扭曲。
TDD給我，作爲開發商，有信心，我做的代碼的變化有預期的後果，只有預期的後果，因此TDD的比喻爲「安全網」是很有用的;在沒有它的系統中更改任何代碼，並且你不知道你可能會破壞什麼。開發人員和測試人員之間
工程緊張是真正的壞消息;開發人員培養一個「好的，測試人員可以找到bug」的思維模式（導致懶惰）和測試人員 - 感覺好像如果他們沒有發現任何錯誤，他們不會被視爲做好自己的工作 - 拋出儘可能多地處理微不足道的問題。這是對每個人時間的嚴重浪費。
最好的軟件開發，在我卑微的經驗，是在測試器也是開發商和單元測試和代碼編寫一起作爲結對編程工作的一部分。這立即將兩個人置於問題的同一方，共同努力實現相同的目標，而不是相互對立。
單元測試是不一樣的功能測試。就自動化而言，通常應該在測試周期重複超過2次或3次時考慮......這是迴歸測試的首選。如果項目很小或者不會經常發生變化或更新，那麼手動測試是一種更好，成本效益更低的選擇。在這種情況下，腳本編寫和維護將會使自動化成本更高。
單元測試可以提供一種代碼形式的文檔，如果代碼作者以外的其他人員需要修改bug或添加新功能/增強功能，那麼這些代碼可能非常有用。開發人員應該測試他們的代碼，但這些測試不應該是唯一的，IMO。 – 2009-03-13 20:54:31