[[354698]]

通過突變測試來修復未知的 bug。

你一定對所有內(nèi)容都進行了測試，也許你甚至在項目倉庫中有一個徽章，標明有 100% 的測試覆蓋率，但是這些測試真的幫到你了嗎？你怎么知道的？

開發(fā)人員很清楚單元測試的成本。測試必須要編寫。有時它們無法按照預期工作：存在假告警或者抖動測試。在不更改任何代碼的情況下有時成功，有時失敗。通過單元測試發(fā)現(xiàn)的小問題很有價值，但是通常它們悄無聲息的出現(xiàn)在開發(fā)人員的機器上，并且在提交到版本控制之前就已得到修復。但真正令人擔憂的問題大多是看不見的。最糟糕的是，丟失的告警是完全不可見的：你看不到?jīng)]能捕獲的錯誤，直到出現(xiàn)在用戶手上 —— 有時甚至連用戶都看不到。

有一種測試可以使不可見的錯誤變?yōu)榭梢姡?ruby>突變測試mutation testing。

變異測試通過算法修改源代碼，并檢查每次測試是否都有“變異體”存活。任何在單元測試中幸存下來的變異體都是問題：這意味著對代碼的修改（可能會引入錯誤）沒有被標準測試套件捕獲。

Python 中用于突變測試的一個框架是 mutmut。

假設你需要編寫代碼來計算鐘表中時針和分針之間的角度，直到最接近的度數(shù)，代碼可能會這樣寫：

def hours_hand(hour, minutes):
    base = (hour % 12 ) * (360 // 12)
    correction = int((minutes / 60) * (360 // 12))
    return base + correction
 
def minutes_hand(hour, minutes):
    return minutes * (360 // 60)
 
def between(hour, minutes):
    return abs(hours_hand(hour, minutes) - minutes_hand(hour, minutes))

首先，寫一個簡單的單元測試：

import angle
 
def test_twelve():
    assert angle.between(12, 00) == 0

足夠了嗎？代碼沒有 if 語句，所以如果你查看覆蓋率：

$ coverage run `which pytest`
============================= test session starts ==============================
platform linux -- Python 3.8.3, pytest-5.4.3, py-1.8.2, pluggy-0.13.1
rootdir: /home/moshez/src/mut-mut-test
collected 1 item                                                              
 
tests/test_angle.py .                                                    [100%]
 
============================== 1 passed in 0.01s ===============================

完美！測試通過，覆蓋率為 100%，你真的是一個測試專家。但是，當你使用突變測試時，覆蓋率會變成多少？

$ mutmut run --paths-to-mutate angle.py
<snip>
Legend for output:
🎉 Killed mutants.   The goal is for everything to end up in this bucket.
⏰ Timeout.          Test suite took 10 times as long as the baseline so were killed.
🤔 Suspicious.       Tests took a long time, but not long enough to be fatal.
🙁 Survived.         This means your tests needs to be expanded.
🔇 Skipped.          Skipped.
<snip>
⠋ 21/21  🎉 5  ⏰ 0  🤔 0  🙁 16  🔇 0

天啊，在 21 個突變體中，有 16 個存活。只有 5 個通過了突變測試，但是，這意味著什么呢？

對于每個突變測試，mutmut 會修改部分源代碼，以模擬潛在的錯誤，修改的一個例子是將 > 比較更改為 >=，查看會發(fā)生什么。如果沒有針對這個邊界條件的單元測試，那么這個突變將會“存活”：這是一個沒有任何測試用例能夠檢測到的潛在錯誤。

是時候編寫更好的單元測試了。很容易檢查使用 results 所做的更改：

$ mutmut results
<snip>
Survived 🙁 (16)
 
---- angle.py (16) ----
 
4-7, 9-14, 16-21
$ mutmut apply 4
$ git diff
diff --git a/angle.py b/angle.py
index b5dca41..3939353 100644
--- a/angle.py
+++ b/angle.py
@@ -1,6 +1,6 @@
 def hours_hand(hour, minutes):
     hour = hour % 12
-    base = hour * (360 // 12)
+    base = hour / (360 // 12)
     correction = int((minutes / 60) * (360 // 12))
     return base + correction

這是 mutmut 執(zhí)行突變的一個典型例子，它會分析源代碼并將運算符更改為不同的運算符：減法變加法。在本例中由乘法變?yōu)槌?。一般來說，單元測試應該在操作符更換時捕獲錯誤。否則，它們將無法有效地測試行為。按照這種邏輯，mutmut 會遍歷源代碼仔細檢查你的測試。

你可以使用 mutmut apply 來應用失敗的突變體。事實證明你幾乎沒有檢查過 hour 參數(shù)是否被正確使用。修復它：

$ git diff
diff --git a/tests/test_angle.py b/tests/test_angle.py
index f51d43a..1a2e4df 100644
--- a/tests/test_angle.py
+++ b/tests/test_angle.py
@@ -2,3 +2,6 @@ import angle
 
 def test_twelve():
     assert angle.between(12, 00) == 0
+
+def test_three():
+    assert angle.between(3, 00) == 90

以前，你只測試了 12 點鐘，現(xiàn)在增加一個 3 點鐘的測試就足夠了嗎？

$ mutmut run --paths-to-mutate angle.py
<snip>
⠋ 21/21  🎉 7  ⏰ 0  🤔 0  🙁 14  🔇 0

這項新測試成功殺死了兩個突變體，比以前更好，當然還有很長的路要走。我不會一一解決剩下的 14 個測試用例，因為我認為模式已經(jīng)很明確了。（你能將它們降低到零嗎？）

變異測試和覆蓋率一樣，是一種工具，它允許你查看測試套件的全面程度。使用它使得測試用例需要改進：那些幸存的突變體中的任何一個都是人類在篡改代碼時可能犯的錯誤，以及潛伏在程序中的隱藏錯誤。繼續(xù)測試，愉快地搜尋 bug 吧。