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

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

基于屬性的測(cè)試和突變測(cè)試

在這篇文章中，我想討論 Java 測(cè)試工具包中兩種成熟但相對(duì)小眾的技術(shù)：使用 Pitest 進(jìn)行突變測(cè)試和使用Jqwik進(jìn)行基于屬性的測(cè)試。我之前寫過關(guān)于PBT和 MT 的文章，帶有開發(fā)人員的帽子和“為技術(shù)而技術(shù)”的心態(tài)。現(xiàn)在，我將戴上 CFO 的預(yù)算批準(zhǔn)帽，并解釋為什么在使用它們之前應(yīng)該三思而后行。但首先，如果您不熟悉這些技術(shù)，請(qǐng)進(jìn)行非常簡潔的復(fù)習(xí)。

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

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

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

讓我們用一個(gè)好的測(cè)試驅(qū)動(dòng)方法的典型例子來詳細(xì)說明。您正在編寫一個(gè)組件，該組件根據(jù)顧客的出生日期計(jì)算入場(chǎng)費(fèi)。幸運(yùn)的是，您的團(tuán)隊(duì)非常注重規(guī)范：

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

該代碼是一組簡單的整數(shù)值 if 語句（請(qǐng)?jiān)徫业娜唛L）。完整代碼在這里。

爪哇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 }

使用像這樣的簡單代碼很容易實(shí)現(xiàn) 100% 堅(jiān)如磐石的覆蓋率。請(qǐng)參閱入學(xué)計(jì)算器套件。對(duì)業(yè)務(wù)規(guī)則的大多數(shù)更改都會(huì)自動(dòng)導(dǎo)致測(cè)試失敗，但不是全部。讓我們引入一個(gè)新規(guī)則。

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

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

您所有的單元測(cè)試仍然通過。類、方法、行甚至分支覆蓋率仍然是 100%。測(cè)試說明了真相，但它不再是全部真相，因?yàn)樵谥?65 附近引入了一個(gè)新的、未經(jīng)測(cè)試的邊緣情況。如果您的工作是測(cè)試驅(qū)動(dòng)的，那么您應(yīng)該在添加新條件之前編寫額外的測(cè)試場(chǎng)景。

當(dāng)突變測(cè)試無濟(jì)于事時(shí)

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

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

用 PBT 捕捉未知的邊緣情況

PBT 在捕捉未經(jīng)測(cè)試的業(yè)務(wù)邏輯添加方面做得很好。單元測(cè)試給你真相，但屬性測(cè)試給你全部真相。由于它驗(yàn)證了 4 到 90 之間的所有值，因此它現(xiàn)在會(huì)在達(dá)到 65 到 90 的范圍時(shí)失敗。

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

從表面上看，上面看起來像是一個(gè)參數(shù)化的測(cè)試

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

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

沒有框架可以挽救低標(biāo)準(zhǔn)的測(cè)試

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

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

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

這些資源密集型框架只有在您將顯著算法正確地隔離為可以測(cè)試數(shù)千次而不會(huì)破壞房屋的小類時(shí)才值得。當(dāng)您將邏輯重構(gòu)為可測(cè)試的塊并提高單元測(cè)試的覆蓋率和質(zhì)量時(shí)，您甚至可能會(huì)發(fā)現(xiàn)不再需要突變測(cè)試。

PBT 和 MT 是令人著迷的技術(shù)，所以一定要看看它們。但它們也是碩士論文的內(nèi)容。他們對(duì)他們有一點(diǎn)學(xué)術(shù)氣息，脫離了質(zhì)量承擔(dān)成本并且必須可以協(xié)商的商業(yè)世界。如果您決定使用它們，請(qǐng)花時(shí)間充分了解它們，不要陷入為測(cè)試而測(cè)試的心態(tài)。