通義靈碼實踐教程——單元測試

點擊此處，立即下載通義靈碼！https://tongyi.aliyun.com/lingma/

通義靈碼加持的單元測試實踐

本文首先講述了什么是單元測試、單元測試的價值、一個好的單元測試所具備的原則，進而引入如何去編寫一個好的單元測試，通義靈碼是如何快速生成單元測試的。

什么是單元測試？

單元測試是一種軟件測試方法，通過編寫代碼來驗證應用程序中最小的可測試單元（如單個函數、方法或類）的正確性。通常，單元測試由開發人員在功能實現過程中或完成后編寫，其目的是確保每個最小可測試單元都能按照設計預期正常工作。

單元測試的價值

單元測試的價值主要體現在提高軟件質量和可靠性，?確保代碼在修改或重構后仍然能夠正常運行。?單元測試的優勢包括：

提高代碼質量：?通過發現代碼中的錯誤和漏洞，?從而提高代碼的質量和可靠性。?
提高開發效率：?在開發過程中及時發現問題，?減少開發周期和成本。?
便于重構和維護：?確保代碼在重構和維護過程中不會出現新的錯誤和漏洞。?
有助于團隊協作：?作為團隊成員之間的溝通和協作工具，?提高團隊的協作效率和質量。?

此外，?單元測試還可以讓軟件故障盡早被發現，?避免故障遺留到后期由于定位修復難度帶來的更大損失。?它的可回歸性為軟件提供了一層安全防護網，?為軟件后續的重構和修改提供了安全保障。?單元測試還為軟件單元如何被使用提供了天然的代碼樣例使用手冊。

遵循的原則

好的單元測試就像空氣（AIR）一樣感覺不到，但在測試質量的保障上，卻是非常關鍵的。好的單元測試宏觀上來說，具有自動化（A）、獨立性（I）、可重復執行（R）的特點。

A: Automatic（自動化）：單元測試應能被自動化執行，以便在代碼更改時快速確認新加入的代碼沒有破壞已有功能，通常情況下會將單測接入到持續集成中，每當代碼有變更時都會通過持續集成自動觸發單元測試。
I: Independent（獨立性）：每個單元測試應當是獨立的，不能依賴于其他測試的執行順序或結果。這也要求單測的測試顆粒度必須足夠小，只有這樣才能滿足獨立性。
R: Repeatable（可重復執行）：好的單元測試在同樣的條件下，每次運行應當給出相同的結果。它不應依賴于外部因素（如網絡、數據庫或文件系統），需要對這些外部的依賴進行正確的mock 。

除此之外，好的單測還必須要滿足有明確的斷言，執行速度快，邊界測試充分，覆蓋率高等特點。只有滿足這些條件的單測才是好的單測，好的單元測試是對代碼質量保障至關重要的一環。

如何編寫單元測試？

下面以Java語言為例來介紹如何編寫單元測試，總體遵循以下幾個步驟：

拆分詳細的測試用例

考慮分支條件

在編寫單元測試時，需要考慮代碼中的所有分支。分支包括if、else、switch語句等，每個分支都需要單獨測試。例如：

public String classifyNumber(int number) {
    if (number < 0) {
        return "negative";
    } else if (number == 0) {
        return "zero";
    } else {
        return "positive";
    }
}

在上述代碼中，有三個分支需要測試：

number<0。
number==0。
number>0。

針對每個分支，都需要編寫一個測試用例。

尋找邊界條件

除了分支，還需要考慮邊界條件。例如，對于上述分類函數，邊界值是-1、0和1。邊界條件測試可以找出可能潛在的問題，確保代碼在極限條件下也能正常工作。

制定統一的單測規范

命名規范

單元測試類通常采用類名Test的形式。例如，如果要測試一個Calculator類，則單元測試類可以命名為CalculatorTest。單元測試方法的命名應當描述具體要測試的內容。例如：

public class CalculatorTest {
    @Test
    public void testAddition() {
        // 測試內容
    }
    @Test
    public void testSubtraction() {
        // 測試內容
    }
}

存放路徑

一般情況下，單元測試類存放的位置在與被測試類相同包名的下面，但在不同的目錄中。在標準的 Maven 項目結構中，源代碼放在src/main/java，單元測試代碼放在src/test/java。

src/main/java/com/example/Calculator.java
src/test/java/com/example/CalculatorTest.java

選擇合適的單測框架

Java 常用的單元測試框架有JUnit和Mockito，下面將圍繞如何使用這兩種框架編寫基本的單元測試：

JUnit 測試框架

JUnit是Java語言中最著名的單元測試框架。它簡潔易用，提供了豐富的注解和斷言。

添加JUnit依賴（以Maven為例）：

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.13.2</version>
  <scope>test</scope>
</dependency>

編寫單元測試：

import org.junit.Test;
import static org.junit.Assert.*;

public class CalculatorTest {
    @Test
    public void testAddition() {
        Calculator calculator = new Calculator();
        assertEquals(5, calculator.add(2, 3));
    }
}

Mockito 測試框架

Mockito是一個強大的模擬框架，用于創建虛擬對象，簡化單元測試，特別是在測試不易創建的依賴對象時非常有用。

添加Mockito依賴：

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>3.11.2</version>
  <scope>test</scope>
</dependency>

編寫單元測試：

import static org.mockito.Mockito.*;
import org.junit.Test;

public class UserServiceTest {
    @Test
    public void testGetUser() {
        UserService userService = new UserService();
        UserRepository mockRepo = mock(UserRepository.class);

        when(mockRepo.findUserById(1)).thenReturn(new User(1, "John Doe"));
        userService.setUserRepository(mockRepo);

        User user = userService.getUserById(1);
        assertNotNull(user);
        assertEquals("John Doe", user.getName());
    }
}

如何使用通義靈碼快速生成單測

在大多數開發者的編程習慣中，通常采用Test Later的方法進行單元測試，即首先編寫好代碼，然后再為代碼編寫相應的單元測試。在此背景下，利用通義靈碼生成單元測試顯得尤為便捷。以下列舉幾種使用通義靈碼生成單元測試的方式。

手工選中代碼方式生成

在 IDE 編輯區中，通過通義靈碼選中某段代碼來生成單測，選中代碼后，在靈碼的問答框內，通過 /generate unit test來生成與選中的代碼對應的單元測試。

說明：使用/generate unit test這個命令時，可以在輸入框追加更多的信息，來生成更符合開發者需要的測試用例，如需要支持JUnit5或采用Mockito進行Mock，就可以采用 /generate unit testJUnit5Mockito這樣的方式，后面兩個關鍵詞被當作前面命令的參數，這樣的使用方式，同樣適用于其他命令。

使用快捷按鈕方式生成

通義靈碼插件在每個方法簽名的上面都會有一個小圖標，單擊圖標后會彈出相應的命令菜單，選擇生成單元測試。

也可以選擇要生成的代碼塊，然后單擊右鍵來選擇生成單元測試功能。

采納單元測試

單測代碼生成完畢后，在問答區的代碼塊右上角，會有三個選項，分別是插入代碼，復制和新建文件：

插入代碼：會將當前生成的單測代碼插入到當前打開的文件中。
復制：即復制代碼塊的代碼，由用戶自行選擇將代碼復制到哪個文件中。
新建文件：會按照Java單測的規范，新生成一個單測類文件，放到指定的目錄中（對應單測方法文件所在的test目錄下），如果已經存在同名的單測文件，需要用戶自主確認是否覆蓋原文件。

單測生成追問

如果您對當前生成的單測代碼不滿意（需要使用特定的單測框架或者生成更多的單測方法），只需在問答區中的輸入框輸入相應的文本進行追問即可，或者也可以單擊預置的單測追問Tag，如示例中追問的Tag ：Retry、Use Mockito、Use Spring Test和Explain code，進行追問，直到生成您滿意的單測代碼為止。

說明：一般根據代碼生成的單元測試，會枚舉常用的測試用例，并不會遍歷所有的用例。如果您覺得生成的用例不足，建議先采納當前生成的幾個用例，放到測試文件當中。然后，切換到測試文件中，采用代碼續寫的方式，通義靈碼會幫助您續寫新的測試用例。

結語

單元測試是重要的編程實踐，為編碼過程搭建質量圍欄。同時，采用測試驅動開發實踐中的Test First ，能夠顯著推動代碼設計的演變。通義靈碼，可以極大降低單元測試框架的搭建和測試用例編寫的工作量。同時，使用通義靈碼對單元測試用例保鮮，可以顯著提升編碼質量。

用通義靈碼維護遺留代碼的正確姿勢

本文首先介紹了遺留代碼的概念，并對遺留代碼進行了分類。針對不同類型的遺留代碼，提供了相應的處理策略。此外，本文重點介紹了通義靈碼在維護遺留代碼過程中能提供哪些支持。

什么是遺留代碼

與過時技術相關的代碼：
- 與不再受支持的操作系統或軟件庫相關的代碼。
- 依賴于已淘汰的技術棧或編程語言的代碼。
為兼容老舊功能而保留的代碼：
- 在現代軟件中為了兼容舊版本功能而保留的代碼片段。
- 為了確保向后兼容性而不得不保留的代碼。
缺乏文檔和維護的代碼：
- 沒有良好文檔支持的舊代碼。
- 缺乏現代開發實踐（如單元測試、代碼審查等）的代碼。

解決遺留代碼的方法

解決遺留代碼有以下三種常見的處理方法：

根據上述描述，補充單元測試是一種有效解決遺留代碼問題的方法。然而，這種方法仍然存在一些問題：

大量遺留代碼缺少單元測試，并且由于代碼間的復雜依賴關系，進行測試的成本非常高。
具體的衡量標準卻不夠清晰，無法定義好的單元測試。
哪些代碼需要添加單元測試？

單元測試常見的誤區

缺乏斷言的假單元測試：開發者可能會采取僅調用函數而不進行斷言的方式，以提高覆蓋率指標，導致了許多無效的單元測試。
把單元測試當成白盒測試：一些觀點將單元測試歸類為白盒測試，但實際上應將其視為針對函數簽名的黑盒測試。
依賴真實環境的單元測試：阻礙單元測試的主要因素包括惰性和依賴環境配置。若不使用Stub或Mock解除對外部環境（如網絡IP、數據庫）的依賴，單元測試將難以達到FIRST原則（快速、獨立、可重復、自我驗證、及時性）。

選擇性的進行單元測試

單元測試除了帶來收益外，本身也會產生一定的成本。如果從收益與成本的角度分析遺留代碼，將有助于明確為遺留代碼補充單元測試的策略，此策略被稱為選擇性單元測試。那么，如何界定成本與收益呢？

遺留代碼單元測試的成本收益象限分類

針對遺留代碼的單元測試，可以根據其成本和收益進行象限分類。根據下圖，對分類標準和各象限進行詳細說明：

分類標準

X軸（成本）：代碼依賴程度越高，測試成本越大。
Y軸（收益）：代碼復雜度越高，質量收益越大。

四個象限

圈復雜度與依賴的概念理解

圈復雜度（Cyclomatic Complexity）：衡量代碼中邏輯分支的數量。
扇入（Fan-In）：直接調用該模塊的上級模塊的個數，扇入大表示模塊的復用程度高。
扇出（Fan-out）：一個模塊直接調用的其他模塊的數量，扇出大表示該模塊依賴其他模塊越多。

不同類型代碼的處理策略

根據上述的分析，遺留代碼的處理策略就變得十分明確：

算法類代碼（Algorithms Code）：生成單元測試。
協調類代碼（Coordinators Code）：進行接口測試。
復雜代碼（Overcomplicated Code）：尋找合適的機會進行重構。
瑣碎代碼（Trivial Code）：不做處理。

使用通義靈碼處理遺留代碼

1. 了解項目工程

在維護一個工程的遺留代碼，首先可通過 @workspace 功能了解整個工程的目的及其涉及的各個模塊。

2. 對不同類型代碼進行處理

針對算法類（Algorithms）代碼生成單元測試

選中需要基于生產代碼進行代碼生成的部分。在生成時，請注意所需的框架及Mock等依賴信息，可以通過生成單元測試命令后追加相關信息進行補充。如 /generate unit testingCppUTest。

一般而言，基于現有代碼生成的單元測試用例數量通常較為有限。如果對單元測試的測試場景及用例數量有具體要求，可以在新生成的單元測試文件中，通過測試函數的續寫方式生成更多的單元測試。在續寫過程中，通義靈碼將盡可能遵循已有用例，以此作為上下文進行參考。

針對協調類代碼（Coordinators）進行接口測試

對于協調類代碼而言，單元測試并不是一種理想的解決方案，由于存在過多的依賴，測試成本顯著提高。針對此類代碼，應該采用接口測試或功能測試的方式進行覆蓋，然而在編寫自動化測試用例時，開發者常常會遇到相關問題。因此，可以通過通義靈碼，快速掌握并理解測試框架。

針對用例的編寫，可以選擇相應的被測函數，并在問答區中直接提問：基于Robot Framework生成以下代碼的測試用例。沿著這一思路，同樣可以實現相應的Keywords等內容。

超復雜的代碼（Overcomplicated Code）找機會進行重構

針對超復雜的代碼，可以使用通義靈碼的 /generate optimization 命令，以獲得針對所選代碼的優化建議。代碼審查與優化將從語法問題、異常改進、代碼整潔度、安全性及風險等多個維度給出相應的優化建議。

針對復雜遺留代碼的優化，并不建議開發者們盲目進行全面的優化和重構。遺留代碼的變更可能會帶來巨大的風險。因此，開發者應根據具體情況，在合適的機會，遵守童子軍法則，進行重構和優化。在這一過程中，通義靈碼也將為您提供有力支持。

結語

以上便是在處理遺留代碼時可參考的實踐。處理遺留代碼需要深入代碼的復雜結構，細致地追蹤每一個可能的分支節點。在這一過程中，除了識別并修復潛在的缺陷外，還必須在有限的時間內完成所有任務。為了避免這一局面的發生，最佳的策略是預防代碼的腐化，善用工具，并在編寫初期遵循良好的編程原則。

posted @ 2024-10-21 16:33 通義靈碼閱讀(386) 評論(0) 收藏舉報

刷新頁面返回頂部

tongyilingma