我有幾個測驗用例，我想通過使用 Jaccard 矩陣的基于相似性的測驗用例選擇方法進行優化。第一步是選擇具有最高相似性指數的一對，然后將其中一個作為候選并洗掉另一個。
我的問題是：您根據哪種策略選擇要洗掉的兩個最相似的測驗用例中的哪一個？尺寸？測驗覆寫率？或者是其他東西？例如這里TC1和TC10具有最高的相似性。你會洗掉哪一個，為什么？
uj5u.com熱心網友回復：
這取決于您為什么這樣做，而靜態代碼指標只能為您提供建議。
如果您試圖使測驗更易于維護，請查找重復的測驗代碼并將其提取到共享代碼中。兩個重要的例子是測驗設定和期望。
例如，如果您傾向于一遍又一遍地進行相同的設定，則可以將其提取到固定裝置或測驗工廠中。您可以使用 setup/teardown methods 和shared contexts等方式共享設定。
如果您發現自己一遍又一遍地執行相同型別的代碼來測驗條件，請將其提取到共享示例中，例如測驗方法或匹配器或共享示例。如果可能，將自定義測驗代碼替換為現有庫中的斷言。
另一個衡量標準是找出測驗過多的測驗。如果單元 A 呼叫單元 B 和 C，則測驗可能會為 B 和 C 進行設定和測驗。這可能是很多額外的作業，使測驗更加復雜，并使單元相互依賴。
由于所有單元 A 關心的是他們對 B 和 C 的特定呼叫是否有效，因此請考慮將對 B 和 C 的呼叫替換為mocks。這可以大大簡化測驗設定和測驗性能，并縮小您測驗的范圍。
但是，要小心。如果 B 或 C 更改 A 可能會中斷，但 A 的單元測驗不會捕捉到這一點。您需要一起為 A、B 和 C 添加集成測驗。幸運的是，這個集成測驗可以非常簡單。它可以相信 A、B 和 C 單獨作業，它們已經過單元測驗，它只需要測驗它們是否一起作業。
如果您這樣做是為了使測驗更快，請首先對測驗進行概要分析以確定它們變慢的原因。
考慮并行化是否有幫助。考慮代碼本身是否太慢。考慮一下代碼是否過于相互依賴，并且為了測驗一件事而不得不做太多的作業。考慮一下您是否真的必須將所有內容寫入磁盤或資料庫等慢速資源，或者有時在記憶體中執行此操作也可以。
認為測驗是多余的是有欺騙性的，因為它們有相似的代碼。類似的測驗可能會測驗非常非常不同的代碼分支。例如，將 1 vs 1.1 傳遞給同一個函式這樣簡單的事情可能會呼叫完全不同的類，一個用于整數，一個用于浮點數。
相反，通過尋找測驗覆寫的相似性來找到冗余。確定測驗是否多余，沒有神奇的相似性百分比，您必須自己確定。
這是因為僅僅因為一行代碼被覆寫并不意味著它已經過測驗。例如...
def test_method
call_a
assert(call_b, 42)
end
此處call_a已涵蓋，但未經測驗。測驗覆寫率只告訴你什么沒有被測驗，它不能告訴你什么已經被測驗。
最后，測驗覆寫冗余是好的。單元測驗、集成測驗、驗收測驗和回歸測驗都可以涵蓋相同的代碼，但從不同的角度來看。
所有靜態分析都可以為您提供冗余的候選者。僅當它們確實是多余的并且僅出于某種目的時才洗掉多余的測驗。簡單重疊的測驗可以作為回歸測驗。很多時候，當單元測驗通過時，我就得救了，但是一些偶然的集成測驗失敗了。重疊是好的。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/453591.html