單元測試不是有寫就好

unit test 要能夠不影響彼此的獨立運作

不能受限與某個時間點或某個服務

單元測試的目的

1. 保護 功能 而不是程式

   1. 保護程式會被程式設計綁架

2. 幫助重構

單元測試應該要像我們的其他程式碼一樣好好地維護

具體地表明此測試在測什麼

「好的」單元測試

1. 暴露意圖

   1. 建立 user 後檢查餘額

   • version 1

     UserObj user = new UserObj();
     user.setName(“Kuma”);
     long userId = userMapper.insert(user);
     AccountObj account = new Account();
     account.setBalance(1,000);
     account.setUser(user.getId());
     accountMapper.insert(account);
     account.getBalance(userId);
     assertEquals(1,000, userId)

   • version 2

     create_user(1,000);
     when_get_balance();
     then_result_is(1,000);

2. 「適當且簡單」的檢查

   1. 驗回傳 > 驗狀態 > 驗互動

   2. 驗回傳

      1. 最接近 User 的的實際狀況

      2. 測試是自己程式的第一個 User

   3. 驗狀態

   4. 驗互動

      1. Mockito.verify(kafkaClient.put(“t”, “hello world”), times(2));

      2. mocking

      3. 被程式實作綁架

      4. 當不得不驗互動的場景越來越多，請回頭看看介面設計有什麼問題。

3. 珍惜生命，遠離框架

4. 測功能，不要測類別 → 獨立於架構

   1. 分開測

      

      1. 組再一起不一定是正常的

   2. 把程式當成黑盒子測試

      

      1. 更放心地重構，不用擔心架構的重構會影響功能

實踐：邊寫邊重構

• 程式功能

• 程式架構

• 測試

三點不動一點不動：TDD

Refs

webconf2023-230823160006-c7e8b338.pdf

中山南路11號.m4a