Pex（及其輸出）適用於企業環境嗎？

Question

我愛的Pex的想法 - 通過靜態代碼分析autogenerating單元測試 - 但實際上是由該工具生成的測試是可怕的，醜陋的，緊耦合的Pex的模塊，難以閱讀和理解等

是這樣的工具是否真的適合（在當前狀態下）用於企業環境，其重點必須放在易於維護上？

或者我誤解了Pex的用途？

Answer 1

確實，您誤解了預期的用途。

Pex是一款白盒測試工具。它基於對應該測試的代碼的分析生成測試用例。其原因是檢測並測試邊緣案例。所以基本上，你甚至不應該改變自動生成的測試。

您的正常單元測試不能被Pex取代。這只是一個額外的工具。

Answer 2

Pex對於測試不依賴於任何外部的複雜算法非常有用。例如，它不會幫助您在SQL語句或文件訪問中找到邊緣案例。但是，爲了找到邊緣案例和增加代碼覆蓋率，除了正常的單元測試之外，它非常有用。

Answer 3

這似乎是一個主觀的問題...

我會說，是的，寫一個給定的框架/ API的測試經常緊耦合到該框架。 Pex的目的不是爲了產生「可讀」的測試，而是爲了確保給定的一組約束條件的代碼覆蓋率。如果這對你的產品有價值，那麼它是合適的 - 當然我會爲給定的團隊和給定的代碼庫投注，這將提供價值。

每個企業都是不同的，但它是決定測試工具適用性的產品和代碼。我建議可以質疑的是Pex對於給定的代碼庫的價值，而不管有問題的組織。

Answer 4

我曾在一家大型金融機構使用pex，並會推薦使用，但僅限於特定情況。我認爲pex擅長它的功能（如本文其他地方所述，用白盒測試來尋找邊緣案例），但由於測試結果非常緊密，因此測試的壽命並不長。

基本上，佩克斯是在產生覆蓋面很大。如果你沒有測試，想要更快一些，請使用Pex。但是，那麼我建議您不要再使用它，而是強制執行新代碼的標準，以符合商定的覆蓋率指標和手寫測試。

通過這種方式，來自pex的脆弱測試將隨着時間的推移而被替換爲更靈活和更高質量的測試。