我們都參加過——甚至可能發表過——演講者特別迷戀某種語言或工具的演講，并且在諸如“簡單地添加此配置鍵或依賴項”之類的短語中過于頻繁地使用該詞。總是推薦一些健康的懷疑來抵消這種熱情，特別是當技術是新的、很少使用的、專業的或三者的組合時。

軟件框架永遠不會免費工作，即使您不支付許可費。不熟悉的技術有一個學習曲線，無論多么溫和。不要告訴我我可以通過“僅”添加一行build.gradle（或二十到pom.xml）來獲得工具 X 的所有好處。特別是應始終將測試工具視為潛在的責任。他們必須通過相應的質量提高來證明其總擁有成本是合理的，而這種更高的質量必須具有商業意義。抱歉打消了你的熱情，但你沒有被聘為藝術家。這樣的等式是不可能用硬數字來表達的。常識必須足夠。

基于屬性的測試和突變測試

在這篇文章中，我想討論 Java 測試工具包中兩種成熟但相對小眾的技術：使用 Pitest 進行突變測試和使用Jqwik進行基于屬性的測試。我之前寫過關于PBT和 MT 的文章，帶有開發人員的帽子和“為技術而技術”的心態。現在，我將戴上 CFO 的預算批準帽，并解釋為什么在使用它們之前應該三思而后行。但首先，如果您不熟悉這些技術，請進行非常簡潔的復習。

突變測試 (MT) 框架對測試中的編譯代碼進行小而重要的更改（突變）。不用擔心，這是在內存中完成的，不會觸及源。JVM 仍然可以運行新的字節碼，但如果您有足夠的覆蓋范圍，更改后的行為現在應該會導致至少一個單元測試失敗。我們稱之為殺死突變體，用游戲玩家的話說。當測試套件的覆蓋率很高但斷言很差時，MT 尤其具有啟發性。許多測試將保持綠色，但 MT 保持綠色是個壞消息。

基于屬性的測試 (PBT) 完全不同。它允許您為屬性定義測試場景，這些屬性是適用于一系列值的真實語句。“未滿 18 歲者不得入內”就是這樣的說法。使用 PBT boolean isAgeAllowed(int age)，可以使用介于 0 到 18 之間的隨機值范圍調用某些方法。有關示例，請參見配套 GitLab 項目中的AdmissionCalculatorPropertySuite 。

MT 是一種質量驗證技術，可在現有測試中發現缺失或不完整的斷言。PBT 通過從多個角度打擊現有測試來增強現有測試。在單元/組件/集成/端到端測試的測試金字塔譜中，它們位于底部。盡管它們存在差異，但它們有一個重要的共同點：它們是可以使結構良好的代碼庫變得更好的工具，但在測試成熟度較低的項目中，它們是無用的，即使不是真正有害的。此外，它們對于有效部署和使用也很重要。

讓我們用一個好的測試驅動方法的典型例子來詳細說明。您正在編寫一個組件，該組件根據顧客的出生日期計算入場費。幸運的是，您的團隊非常注重規范：

• 一個人的年齡必須評估為非負值。帶有“出生日期無效”的信號例外。
• 4 歲以下的兒童或 90 歲以上的成人不得參加這個可怕的主題公園游樂設施。帶有“顧客必須在 4 到 90 歲之間”的信號例外。
• 15 歲或以下的入場費為 10 歐元，16 歲及以上的入場費為 15 歐元。

該代碼是一組簡單的整數值 if 語句（請原諒我的冗長）。完整代碼在這里。

爪哇1 如果（年齡 < 0）{2 throw new IllegalArgumentException ( "出生日期 [%s] 無效" . formatted ( dateOfBirth ));3 } else if (年齡 < 4 || 年齡 > 90 ) {4 throw new IllegalArgumentException ( "顧客必須在 4 到 90 歲之間，但是是 [%s]" .formatted ( age ) ); 5 }否則 如果（年齡 < 16）{6 返回 10 ;7 }其他{8 返回 15 ;9 }

使用像這樣的簡單代碼很容易實現 100% 堅如磐石的覆蓋率。請參閱入學計算器套件。對業務規則的大多數更改都會自動導致測試失敗，但不是全部。讓我們引入一個新規則。

65 歲或以上的成年人支付 10 歐元。

因此，兒童和老年人有資格享受折扣。就代碼而言：if (age < 16)變為if (age < 16 || age >= 65)

您所有的單元測試仍然通過。類、方法、行甚至分支覆蓋率仍然是 100%。測試說明了真相，但它不再是全部真相，因為在值 65 附近引入了一個新的、未經測試的邊緣情況。如果您的工作是測試驅動的，那么您應該在添加新條件之前編寫額外的測試場景。

當突變測試無濟于事時

MT能抓住這個遺漏嗎？是的，它可能已更改age >= 65為age > 65并提醒您沒有測試來涵蓋這種邊緣情況。但是在實施更改時，您可以而且應該注意到它。您可以正確地爭辯說，生產代碼從來沒有像這個例子那樣微不足道。當您繼承大型代碼庫時，MT 肯定更有助于提高測試質量嗎？以下是我可能不是的原因。

• 當測試套件的斷言很差時，您不需要 MT 告訴您。在 src/test/java 中對 'assert' 進行全文搜索會告訴您您需要知道的一切。
• 您不需要 MT 來檢查測試覆蓋率。有更有效的工具可以做到這一點。如果發現大部分代碼，首先，MT 無法產生任何有用的東西，因為沒有測試代碼可以殺死突變體。
• 像 Pitest 這樣的工具可以生成非常精確但也很詳細的關于潛入雷達的突變體的報告。如果你有很好的覆蓋范圍但斷言很差，這將是巨大的。這就像一個所有警告燈同時閃爍的 747 駕駛艙。知道首先要解決哪個問題需要判斷。殺死所有的變種人是沒有意義的，因為 100% 的測試覆蓋率通常是不值得的。
• MT 框架為每個突變體多次運行相同的測試場景，因此被測代碼應該快速執行。訪問數據庫、文件系統或網絡會使突變測試運行速度慢得令人無法接受。同樣，具有長方法和高圈復雜度的非內聚代碼創造了許多引入突變的機會。相同的 long 方法將被調用無數次。

用 PBT 捕捉未知的邊緣情況

PBT 在捕捉未經測試的業務邏輯添加方面做得很好。單元測試給你真相，但屬性測試給你全部真相。由于它驗證了 4 到 90 之間的所有值，因此它現在會在達到 65 到 90 的范圍時失敗。

爪哇1@財產2公共 voidany_age_between_four_and_ninety_is_valid ( @ForAll @IntRange ( min = 4 , max = 90 ) int age ) {3 斷言（getAdmissionForAge（年齡））。是積極的（）；4}

從表面上看，上面看起來像是一個參數化的測試

爪哇1@ParameterizedTest2@ValueSource ( ints = { 4 , 90 })3公共 無效
any_age_between_four_and_ninety_is_valid（整數 年齡）{4... }5

不過，不要被愚弄。上面的單元測試不測試“任何年齡”，只測試我們碰巧知道的邊緣情況。使用 PBT 作為一種霰彈槍方法來殺死你忘記的邊緣情況是很誘人的，但這與它的精神背道而馳。您應該從記錄的屬性開始，并將它們轉換為可運行的測試用例。指定這些屬性應該在測試和生產代碼之前。

沒有框架可以挽救低標準的測試

當測試成熟度較差的團隊編寫單元測試時，通常是為了確認生產代碼的作用。給定值 X 和 Y，被測方法返回 Z，這就是我們所斷言的。用一千個不同的值（如 PBT 所做的那樣）來打擊它似乎毫無意義。如果你的自動化測試只是像那樣鞏固現狀，那確實是毫無意義的。您可以從這種方法中獲得的最好的結果是對回歸的一些保護。PBT 和 MT 都不會幫助您。他們無法揭示實施中的邏輯判斷失誤，更不用說解釋設計時的錯誤了。一開始可能沒有。

MT 和 PBT 在經過良好測試的關鍵業務代碼中具有價值，其中充滿了 if 語句、開關和（數字）邊緣情況，您需要金錢可以買到的所有穩健性。相反，如果一個方法對任何浮點值的行為都是可預測的，那么用隨機輸入對其進行一千次測試并不會給你太多的洞察力。

不要將這些框架用于支持功能，即支持應用程序算法核心的代碼：Web 或消息傳遞端點、數據庫訪問層、安全層或數據傳輸映射邏輯。不要編寫遇到此類代碼的 PBT 場景，并確保 Pitest 忽略這些部分進行突變。

這些資源密集型框架只有在您將顯著算法正確地隔離為可以測試數千次而不會破壞房屋的小類時才值得。當您將邏輯重構為可測試的塊并提高單元測試的覆蓋率和質量時，您甚至可能會發現不再需要突變測試。

PBT 和 MT 是令人著迷的技術，所以一定要看看它們。但它們也是碩士論文的內容。他們對他們有一點學術氣息，脫離了質量承擔成本并且必須可以協商的商業世界。如果您決定使用它們，請花時間充分了解它們，不要陷入為測試而測試的心態。