在Python測試中,我們爲什麼要這樣寫:爲什麼不在測試中使用python的assert語句?
self.assertEqual(response.status_code, 200)
self.assertIn('key', my_dict)
self.assertIsNotNone(thing)
而不是在自然:
assert response.status_code == 200
assert 'key' in my_dict
assert thing is not None
對於許多情況下,斷言輔助方法生成的失敗消息沒有任何可讀性更強(可以說單元測試的camelCase風格是不太可讀的)。
背景我的項目:
- 我們一直在利用現代測試運行,如鼻子或py.test,我們真的不關心單元測試亞軍。測試發現甚至不關心這個類是否最終繼承了
unittest.TestCase
,或者你是否在類內工作。 - 我們絕不會使用-O切換到解釋器來執行自動化測試。
- 當我們想要一個更可讀的消息時,單元測試的默認值通常不夠好 - 例如,有一個不同的值,嵌套在json數據的某個地方,我們希望看到一個上下文差異。
核心庫和CPython測試仍然通常以單元測試風格編寫,並且他們通常會做所有事情都有很好的理由。所以我的問題是,在單元測試的風格之外工作是可以的,還是有一些我缺少的缺點 - 爲什麼不在測試中使用assert?爲什麼核心開發者沒有從單元測試中移走呢?
增編:docs確實提到一個原因:
這些方法中使用的斷言語句代替測試運行器能夠積累所有的測試結果併產生一個報告
然而,這種理由似乎是假的,即使你使用斷言語句,測試運行者也可以像往常一樣積累結果和報告。 unutbu在related post中表示unittest將會提出一個AssertionError
,就像斷言聲明一樣,並且這已經超過7年了,所以它也不是一個閃亮的新特性。
我工作到'unittest',我使用'print()'而不是'assert'。我認爲這一切都取決於項目的複雜性和規模。 – TigerhawkT3
這似乎主要是一個意見問題。如果你認爲'assert'優越,那麼沒有什麼能夠防止(除了你的同事可能不同意)你不使用它。但是應該知道,您可能會重寫'TestCase'類中的方法並自定義行爲 - 'assert'語句沒有這種靈活性。另外'TestCase.failureException'可能會被改變,這會使你的觀點變得無效,因爲它是從'assert'語句拋出的異常(如果你想考慮'assert'錯誤而不是失敗),就可以使用它。 – skyking
只是簡單的'assert'更具可讀性。所以如果你的測試失敗,總是使用'pytest'。 – o11c