我知道這是主觀的，但我想遵循最常見的做法。 您是否通常爲每個類方法創建一個測試方法，並使用多個斷言來填充它，或者是否爲每個斷言創建一個測試方法？我應該爲每個斷言創建一個新的測試方法嗎？
例如，如果我測試一個銀行帳戶的withdraw方法，我想確保，如果用戶試圖透支帳戶或撤銷負數拋出一個異常，我應該創建testOverdaw和testNegativeWithdrawal，或將我只是將這兩個斷言結合在一個名爲testWithdraw的方法中？
想想這樣：每個測試都應該獨立運行，並且運行一組相對獨立的功能。如果您想斷言您所創建的某種方法是否有三件事是真的，那麼您應該創建一個包含這三件事的測試。
因此，我不得不強烈反對其他人的回答。任意限制自己對每個測試的一個斷言將不會爲你做任何事情，除非讓你的測試笨重和乏味。最終它可能會讓你完全失望 - 這肯定是一種恥辱：對你的項目和職業不利。
現在，而不是表示您有許可編寫大型，笨重或多用途測試例程。的確，我認爲我從來沒有寫過20行左右的文章。
只要知道哪一個斷言失敗時，在一個函數中有幾個，你會注意到當斷言失敗時，nUnit和MSTest都會給你一個描述和一個鏈接，它會將你帶到違規行（nUnit將需要一個集成工具，如TestDriven.net）。這使得找出失敗點微不足道。兩者都會停止在函數中的第一次失敗，並且都會讓您有能力進行調試演練。
我同意這一點，但我看到這種方法的一個缺點。如果您正在執行三個斷言來測試三種不同的場景，並且在運行測試時第一個失敗。另外兩個斷言呢？你不知道他們是否會成功或失敗。你打破了你的三個場景還是隻有一個或兩個？任何雖然？ – joerage 2009-12-14 02:10:33
好問題。首先，請記住，測試中的所有斷言應該是相關的。如果失敗了，這可能會對其他人產生影響。因此，在確定其他人之前，我必須解決第一個問題。其次，在我的工作風格中，失敗的測試是立即修復的原因。所以我不擔心其他兩個，直到我得到第一個固定。也就是說，我將在緊密循環中修復和測試該功能，直到所有功能都得到驗證。所以，如果其他人失敗了，我可以通過修正第一個來解決它們。如果他們沒有失敗，重新測試會立即告訴我。 – 2009-12-14 03:59:36
@joerage爲什麼不解決問題，重新運行測試並查看其他聲明是否失敗？ – cbp 2009-12-15 00:07:01
做出多種測試方法;不要把它們合併成一個。每種測試方法都應該測試方法的一種行爲。正如你所說，測試時使用負平衡是一種不同的行爲，然後以正平衡進行測試。所以，這將是兩個測試。
你想這樣做，這樣當一個測試失敗時，你不會試圖找出那個測試中的哪個部分失敗。
就我個人而言，我會爲每個斷言創建一個測試，否則您必須挖掘以找出失敗的原因，而不是從測試名稱中顯而易見。
如果您必須編寫幾行代碼來設置測試並且不想重複測試，那麼根據您的語言和測試框架，您應該能夠創建一組測試，其中每個測試都將執行它運行之前的一段代碼。
+1 ...餘額 – Paul 2009-12-14 01:20:55
我會建議有一個測試方法每個斷言，或者說是一個預期的行爲。這樣可以更快地定位錯誤代碼，如果有任何測試失敗。
我會做出這兩個單獨的斷言。
第一個表示如果用戶定期使用該帳戶會發生的有效操作，第二個表示數據清理未完成或未正確完成的情況。
您需要單獨的測試用例，以便您可以根據需要在邏輯上實施測試用例，尤其是在迴歸場景中，運行所有測試的成本過高。
其中一種方法是針對每種不同場景或設置使用一種單獨的方法。在您的情況下，您可能需要一個場景，其中有足夠的資金，以及一個場景資金不足。並斷言在第一個一切正常，並在第二個相同的操作不起作用。
testOverdraw和testNegativeWithdrawal是兩個單獨的行爲。他們應該分開測試。
一個很好的經驗法則是在一個單元測試中對被測方法只有一個動作（不包括設置和斷言）。
從NUnit文檔： 「如果斷言失敗，方法調用不會返回並報告錯誤。如果測試包含多個斷言，那麼失敗的後面的任何斷言都不會執行。 ，通常每個測試都要嘗試一個斷言。「
http://www.nunit.org/index.php?p=assertions&r=2.4.6
然而，沒有任何強迫你遵循最佳做法。如果這個特定項目不值得花時間和精力進行100％細粒度測試，其中一個bug意味着一個測試失敗（反之亦然），那麼不要這樣做。最終，它是一種工具，您可以使用最佳的成本/收益平衡。這種平衡取決於許多特定於您的方案的變量，並且針對每個項目。
在我看來，你至少應該測試0和max（數字），這樣做很明顯，它只是簡單到最後有一個已知的初始狀態，並使它們都是單獨的測試。 – 2009-12-14 08:28:03