過去我們一直的都在倡導著開發者需進行所謂的單元測試。

單元測試是個相當有效的工程實踐, 這是無庸置疑的。但是, 全世界大部分的開發人員是都沒有在寫單元測試的。

為什麼 ?

主要的原因如下:

  1. 粒度過小的單元測試用例是很難進行維護與擴展的:

針對這個問題, 我們必需要有個輕量級、可視化的方法, 可協助開發人員找到真正值得進行測試的關鍵路徑。

只針對關鍵路徑進行測試用例的開發, 才不會形成粒度過小的測試用例;  粒度過小的測試用例將會難以的進行維護, 最終只好宣布放棄。

Story 場景樹是個相當好的方法,可協助開發人員找到真正值得進行測試的關鍵路徑。

Story 場景樹

2. 單元測試的寫法尚不夠簡潔:

單元測試往往都會寫得過於的片斷, 無形中就會很容易的遺漏掉應該測試的場景。

針對這個問題, Property-Based Testing 是個相當好的解決方案。

Property-Based Testing 能以 @given 的方式生成測試數據; 而能以測試數據驅動的方式, 在單一的測試用例中完成多個不同的場景的測試; 使得開發人員能以少量的測試代碼, 完成更有效、更完整的測試場景的測試。

@given(st.lists(st.integers())) 
def test_sort(XS):
    sorted_xs = quicksort(XS)
    assert isinstance(sorted_xs, list)
    assert Counter(XS) == Counter(sorted_xs) 
    assert all(
        x <= y for x, y in
        zip(sorted_xs, sorted_xs[1:]
    )

3. 單元測試的 Mock 並沒有發揮其應有的功能

單元測試的 Mock 的機制, 並沒有能真正的高效、有效的使得開發人員在開發的階段, 就能得知自身代碼的變更對其他開發人員所負責的代碼的影響。

針對這個問題, Contract Testing 是個相當好的解決方案。

在 Pack 的配置文件中, 配置好 Billing Service 與 User Service 間交互的命令、請求與響應。Pack 便會是 User Service 的代理; Billing Service 便可獨立的與 Pack 進行整合測試。Billing Service 的開發人員在開發的階段就能得知自身代碼的變更對 User Service 的影響。
User Service 的開發人員在開發的階段, 因在 User Service 上代碼的變更, 而使 Billing Service 無法獲取到所預期的響應。

單元測試啟蒙了我們應該如何的去開發高質量的代碼。 

開發者測試; Story 場景樹, Property_Based Testing , Contract Testing; 使得我們能真正高效率、有效的去開發高質量的代碼。

發表評論

電子郵件地址不會被公開。 必填項已用*標註

此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據