Rust 單元測試與整合測試最佳實踐

Rust 的單元測試框架預設平行執行，處理全域狀態時需注意執行緒安全。lazy_static 可用於初始化全域變數，但測試間同步需使用 Mutex 等同步原語。Atomic 型別則適用於原子操作。Send 和 Sync 特質確保跨執行緒分享狀態的安全性。重構時，單元測試能避免迴歸錯誤，rustfmt 和 rust-analyzer 等工具可輔助重構過程。proptest 函式庫則適用於屬性測試，自動生成測試案例。cargo-tarpaulin 可生成程式碼覆寫率報告，找出未被測試覆寫的程式碼路徑。整合測試驗證公開介面，位於專案的 tests 目錄，由 Cargo 自動發現並執行。良好的整合測試能提升使用者經驗，避免設計上的「隧道視野」。快速排序演算法的例子展示瞭如何透過 trait 改善介面設計。Rust 內建的整合測試機制已足夠，但特定情況下也可使用外部工具。使用 Rust 撰寫整合測試的優勢之一是跨平台相容性。

單元測試中的平行處理與全域狀態管理

在 Rust 中進行單元測試時，處理平行測試案例和全域狀態是一個重要的課題。由於 Rust 的測試框架預設會平行執行測試，因此在測試中若使用全域狀態，需要特別注意執行緒安全。

全域狀態的問題

首先，我們來看看一個簡單的例子，展示了在測試中使用可變全域狀態的問題：

#[cfg(test)]
mod tests {
    static mut COUNT: i32 = 0;

    #[test]
    fn test_count() {
        unsafe {
            COUNT += 1;
        }
    }
}

這段程式碼無法透過編譯，因為 Rust 編譯器會正確地捕捉到使用可變全域狀態的錯誤。編譯錯誤如下：

error[E0133]: use of mutable static is unsafe and requires unsafe function or block
 --> src/lib.rs:7:9
  |
7 |         COUNT += 1;
  |         ^^^^^^^^^^^^ use of mutable static
  |
  = note: mutable statics can be mutated by multiple threads: aliasing violations or data races will cause undefined behavior

為什麼不能直接使用可變全域狀態？

Rust 編譯器嚴格檢查可變全域狀態的使用，因為在多執行緒環境下，這可能會導致資料競爭和未定義行為。

使用原子變數解決問題

為了避免上述問題，我們可以使用 AtomicI32 來取代普通的 i32。AtomicI32 是執行緒安全的，可以用於多執行緒環境下的計數。

#[cfg(test)]
mod tests {
    use std::sync::atomic::{AtomicI32, Ordering};

    static COUNT: AtomicI32 = AtomicI32::new(0);

    #[test]
    fn test_count() {
        COUNT.fetch_add(1, Ordering::SeqCst);
    }
}

不過，即使用 AtomicI32，我們仍然需要處理全域變數的初始化問題。

使用 `lazy_static` 初始化全域變數

lazy_static 提供了一種機制，讓我們可以在第一次存取全域變數時才進行初始化。這解決了 Rust 不允許在全域作用域中呼叫非 const 函式的問題。

#[cfg(test)]
mod tests {
    use lazy_static::lazy_static;
    use std::sync::atomic::{AtomicI32, Ordering};
    use std::sync::Arc;

    lazy_static! {
        static ref COUNT: Arc<AtomicI32> = Arc::new(AtomicI32::new(0));
    }

    #[test]
    fn test_count() {
        let count = Arc::clone(&COUNT);
        count.fetch_add(1, Ordering::SeqCst);
    }
}

`lazy_static` 的工作原理

lazy_static 宏會在編譯期生成必要的程式碼，以確保全域變數在第一次存取時被初始化。它內部使用了 std::sync::Once 來保證初始化過程是執行緒安全的。

Send 和 Sync 特質

Rust 的 Send 和 Sync 特質對於處理跨執行緒的分享狀態至關重要。Send 表示一個物件可以安全地在執行緒之間移動，而 Sync 表示一個物件可以安全地在多個執行緒之間分享。

這些特質是由編譯器自動派生的，我們可以透過使用 Arc、Mutex 和 RwLock 等同步原語來實作執行緒安全。

重構與單元測試的最佳實踐

單元測試在軟體開發中扮演著至關重要的角色，尤其是在進行程式碼重構時。良好的單元測試能夠確保軟體在變更過程中保持原有的功能和行為，避免迴歸錯誤的引入。

平行測試中的特殊案例與全域狀態管理

在撰寫單元測試時，經常會遇到需要共用全域狀態的情況。Rust 的 lazy_static 套件提供了一個解決方案，用於初始化和管理全域變數。例如：

#[cfg(test)]
mod tests {
    use lazy_static::lazy_static;
    use std::sync::atomic::{AtomicI32, Ordering};

    lazy_static! {
        static ref COUNT: AtomicI32 = AtomicI32::new(0);
    }

    #[test]
    fn test_count() {
        COUNT.fetch_add(1, Ordering::SeqCst);
    }
}

內容解密：

lazy_static 宏用於宣告一個全域的 AtomicI32 變數 COUNT，並初始化為 0。
在 test_count 測試中，COUNT 的值透過 fetch_add 方法原子性地增加 1。
Ordering::SeqCst 確保操作的順序一致性。

然而，lazy_static 並不能解決測試之間的同步問題。如果需要確保測試按順序執行，可以使用 std::sync::Mutex 進行同步：

#[cfg(test)]
mod tests {
    use lazy_static::lazy_static;
    use std::sync::Mutex;

    lazy_static! {
        static ref MUTEX: Mutex<i32> = Mutex::new(0);
    }

    #[test]
    fn first_test() {
        let _guard = MUTEX.lock().expect("couldn't acquire lock");
        println!("first test is running");
    }

    #[test]
    fn second_test() {
        let _guard = MUTEX.lock().expect("couldn't acquire lock");
        println!("second test is running");
    }
}

內容解密：

使用 Mutex 來同步測試，確保一次只有一個測試在執行。
_guard 的存在確保了鎖在測試結束後被釋放。

重構的價值與風險

重構是改善程式碼品質、提升效能的重要手段，但同時也伴隨著引入迴歸錯誤的風險。良好的單元測試能夠在重構過程中提供信心，確保變更不會破壞現有的功能。

重構工具

Rust 提供了多種工具來輔助重構，包括：

rustfmt：用於格式化程式碼，統一程式碼風格。
rust-analyzer：提供智慧的重新命名和結構化搜尋替換功能，能夠安全地進行變數和函式的重新命名。

例如，使用 rust-analyzer 的結構化搜尋替換功能，可以將 $m.lock() 替換為 Mutex::lock(&$m)，如下圖所示：

此圖示說明瞭使用 rust-analyzer 進行結構化替換的操作過程。

圖表解說：

圖表展示了使用 rust-analyzer 的結構化搜尋替換功能，將特定模式的程式碼進行替換。
這種方法能夠避免手動替換可能帶來的錯誤。

最佳實踐

適度測試：過多的測試會使軟體變得僵化，難以變更。應根據規格需求進行測試。
結合多種測試工具：如屬性基礎測試（property-based testing）、模糊測試（fuzz testing）和程式碼覆寫率分析（code coverage analysis），能夠在保證品質的同時提供靈活性。

綜上所述，良好的單元測試和適當的重構工具能夠顯著提升軟體開發的效率和品質。開發者應當根據具體需求選擇合適的測試策略和重構方法，以達到最佳的開發效果。

單元測試：確保程式碼品質的利器

單元測試是軟體開發中的重要環節，尤其是在 Rust 這種強調安全性和效能的語言中更是如此。透過單元測試，開發者可以確保程式碼的正確性、穩定性和可維護性。

重構工具：提升開發效率

Rust Analyzer 提供了一系列的重構工具，幫助開發者更輕鬆地維護和最佳化程式碼。這些工具包括：

結構化搜尋和替換：允許開發者使用語法結構來搜尋和替換程式碼，而非簡單的文字比對。
重寫：當需要重寫大量程式碼或演算法時，可以使用 proptest 函式庫來確保新程式碼的正確性。

結構化搜尋和替換

結構化搜尋和替換是 Rust Analyzer 的一項強大功能。它允許開發者指定語法結構來進行搜尋和替換，而非簡單的文字比對。例如，將 MUTEX.lock() 替換為 Mutex::lock(&MUTEX)。這種方法可以根據程式碼的上下文進行智慧替換。

// 搜尋模式
Mutex::lock($arg)

// 替換模式
Mutex::lock(&$arg)

重寫與屬性測試

當需要重寫大量程式碼或演算法時，使用 proptest 函式庫可以確保新程式碼的正確性。proptest 是一種屬性測試框架，可以自動生成測試案例來驗證程式碼的屬性。

use proptest::prelude::*;

proptest! {
    #[test]
    fn test_better_fizzbuzz_proptest(n in 1i32..10000) {
        assert_eq!(fizzbuzz(n), better_fizzbuzz(n))
    }
}

程式碼覆寫率：衡量測試的有效性

程式碼覆寫率是衡量測試有效性的重要指標。Rust 提供了 cargo-tarpaulin 工具來生成程式碼覆寫率報告。透過分析覆寫率報告，開發者可以找出未被測試覆寫的程式碼路徑，從而改進測試。

使用 cargo-tarpaulin 生成覆寫率報告

cargo install cargo-tarpaulin
cargo tarpaulin --out Html

處理不斷變化的生態系統

Rust 的生態系統不斷發展，新的函式庫和工具不斷湧現。這給維護帶來了挑戰，但也提供了機遇。透過單元測試，開發者可以確保程式碼在不斷變化的生態系統中保持穩定和正確。

重點回顧

Rust 的強型別系統和編譯器減少了執行時錯誤的可能性。
使用 proptest 進行屬性測試可以提高測試的有效性。
程式碼覆寫率分析有助於找出未被測試覆寫的程式碼路徑。
單元測試在處理不斷變化的生態系統中扮演著重要角色。

透過遵循這些最佳實踐，Rust 開發者可以編寫出更高品質、更穩定的程式碼。

整合測試：確保軟體品質的關鍵策略

在第6章中，我們探討了Rust中的單元測試。在本章中，我們將討論如何在Rust中使用整合測試，以及它與單元測試的比較。單元測試和整合測試都是提高軟體品質的強大策略，它們經常一起使用，但目標略有不同。

7.1 整合測試與單元測試的比較

整合測試是測試個別模組或群組的公開介面。與此相反，單元測試是測試軟體中最小的可測試元件，有時包括私有介面。公開介面是那些暴露給軟體外部使用者的介面，例如公共函式庫介面或命令列應用程式的CLI命令。

在Rust中，整合測試與單元測試幾乎沒有共同點。與單元測試不同，整合測試位於主要原始碼樹之外。Rust將整合測試視為獨立的crate；因此，它們只能存取公開匯出的函式和結構。

快速排序演算法的實作

讓我們寫一個快速排序演算法（https://en.wikipedia.org/wiki/Quicksort）的通用實作，如下所示。

pub fn quicksort<T: std::cmp::PartialOrd + Clone>(slice: &mut [T]) {
    if slice.len() < 2 {
        return;
    }
    let (left, right) = partition(slice);
    quicksort(left);
    quicksort(right);
}

fn partition<T: std::cmp::PartialOrd + Clone>(slice: &mut [T]) -> (&mut [T], &mut [T]) {
    let pivot_value = slice[slice.len() - 1].clone();
    let mut pivot_index = 0;
    for i in 0..slice.len() {
        if slice[i] <= pivot_value {
            slice.swap(i, pivot_index);
            pivot_index += 1;
        }
    }
    if pivot_index < slice.len() - 1 {
        slice.swap(pivot_index, slice.len() - 1);
    }
    slice.split_at_mut(pivot_index - 1)
}

整合測試的目錄結構

整合測試位於原始碼樹頂層的tests目錄中。這些測試由Cargo自動發現。一個小型函式庫（在src/lib.rs中）和單個整合測試的目錄結構範例如下：

.
├── Cargo.lock
├── Cargo.toml
├── src
│   └── lib.rs
└── tests
    └── quicksort.rs

整合測試的撰寫

測試函式使用#[test]屬性標記，該屬性將由Cargo自動執行。我們可以使用自動提供的main()函式，也可以像單元測試一樣提供自己的main()函式。

use quicksort::quicksort;

#[test]
fn test_quicksort() {
    let mut values = vec![12, 1, 5, 0, 6, 2];
    quicksort(&mut values);
    assert_eq!(values, vec![0, 1, 2, 5, 6, 12]);
    let mut values = vec![1, 13, 5, 10, 6, 2, 0];
    quicksort(&mut values);
    assert_eq!(values, vec![0, 1, 2, 5, 6, 10, 13]);
}

與單元測試的比較

這看起來與單元測試非常相似。事實上，這個程式碼範例中包含了單元測試，它們看起來幾乎相同。

#[cfg(test)]
mod tests {
    use crate::{partition, quicksort};

    #[test]
    fn test_partition() {
        let mut values = vec![0, 1, 2, 3];
        assert_eq!(
            partition(&mut values),
            (vec![0, 1, 2].as_mut_slice(), vec![3].as_mut_slice())
        );
        // ...
    }

    #[test]
    fn test_quicksort() {
        let mut values = vec![1, 5, 0, 6, 2];
        quicksort(&mut values);
        assert_eq!(values, vec![0, 1, 2, 5, 6]);
        // ...
    }
}

#### 程式碼解析：

quicksort函式：對輸入的切片進行快速排序，使用遞迴方式實作。
partition函式：將切片分成兩部分，小於基準值的元素在左邊，大於基準值的元素在右邊。
test_quicksort函式：測試quicksort函式的正確性，使用不同的輸入進行驗證。
test_partition函式：測試partition函式的正確性，驗證分割結果是否正確。

整合測試策略的深度探討

撰寫整合測試不僅是驗證程式碼正確性的手段，更是評估軟體使用者經驗（UX）的有效途徑。良好的軟體設計能夠提升使用者滿意度，而整合測試的過程迫使開發者站在使用者的角度審視設計本身，避免陷入「隧道視野」，忽略整體架構的重要性。

隧道視野的陷阱與反思

開發過程中很容易專注於區域性實作，忽略整體設計的合理性。以 dryoc 函式庫的開發經驗為例，當時過度複雜的選用功能設計，直到撰寫整合測試時才發現介面設計不良，迫使進行大幅度的重構，以提升函式庫的易用性。

TDD 與整合測試的實踐順序

是否應該在開發前就撰寫整合測試？雖然這不是常見的做法，但也不一定是壞事，開發者應根據實際經驗判斷是否適合採用測試驅動開發（TDD）。然而，撰寫整合測試有助於站在使用者角度思考設計的合理性，至於測試的撰寫順序則可依個人習慣調整。重要的是保持設計的彈性，並勇於重構。

當我正在解決一個問題時，我從不考慮美觀，但當我完成時，如果解決方案不美觀，我知道它一定是錯的。
— R. Buckminster Fuller

介面設計的最佳化實踐

前述的快速排序範例展示瞭如何透過整合測試改善介面設計。原本獨立的 quicksort() 函式可進一步 Rust 化，透過建立 trait 並實作該 trait 來提升程式碼的可讀性和一致性。

程式碼範例：Quicksort Trait 的實作

pub trait Quicksort {
    fn quicksort(&mut self) {}
}

impl<T: std::cmp::PartialOrd + Clone> Quicksort for [T] {
    fn quicksort(&mut self) {
        quicksort(self);
    }
}

內容解密：

定義 Quicksort Trait：宣告 quicksort 方法，讓資料型別能夠呼叫該方法進行排序。
泛型實作：為實作 PartialOrd 和 Clone 特性的切片型別提供預設實作，使其能夠直接呼叫 quicksort。
直接呼叫內部實作：在 trait 方法中直接呼叫已有的 quicksort 函式，保持邏輯的一致性。

更新後的測試程式碼

#[test]
fn test_quicksort_trait() {
    use quicksort_trait::Quicksort;
    let mut values = vec![12, 1, 5, 0, 6, 2];
    values.quicksort();
    assert_eq!(values, vec![0, 1, 2, 5, 6, 12]);
    let mut values = vec![1, 13, 5, 10, 6, 2, 0];
    values.quicksort();
    assert_eq!(values, vec![0, 1, 2, 5, 6, 10, 13]);
}

內容解密：

引入 Quicksort Trait：透過 use 陳述將 trait 引入作用域，使切片型別具備 quicksort 方法。
簡化呼叫語法：將 quicksort(&mut values) 改為 values.quicksort()，減少語法複雜度並提升可讀性。

內建整合測試與外部工具的比較

Rust 的內建整合測試機制已能滿足大多數需求，但某些情況下，使用外部工具可能更為合適。例如，測試 HTTP 服務時，使用 curl 或 HTTPie 等通用工具可能更為便捷。對於命令列應用程式，使用 Bash、Ruby 或 Python 等動態語言撰寫整合測試可能更有效率，因為這些語言更適合快速開發非效能關鍵的測試指令碼。

平台相容性的考量

僅使用 Rust 編寫整合測試的一個顯著優勢是跨平台相容性，無需額外的外部工具，僅需 Rust 工具鏈即可執行所有測試。這在某些環境下具有明顯優勢，尤其是需要在多種平台上執行的專案。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

Rust 單元測試與整合測試最佳實踐

單元測試中的平行處理與全域狀態管理

全域狀態的問題

為什麼不能直接使用可變全域狀態？

使用原子變數解決問題

使用 lazy_static 初始化全域變數

lazy_static 的工作原理

Send 和 Sync 特質

重構與單元測試的最佳實踐

平行測試中的特殊案例與全域狀態管理

內容解密：

內容解密：

重構的價值與風險

重構工具

圖表解說：

最佳實踐

單元測試：確保程式碼品質的利器

重構工具：提升開發效率

結構化搜尋和替換

重寫與屬性測試

程式碼覆寫率：衡量測試的有效性

使用 cargo-tarpaulin 生成覆寫率報告

處理不斷變化的生態系統

重點回顧

整合測試：確保軟體品質的關鍵策略

7.1 整合測試與單元測試的比較

快速排序演算法的實作

整合測試的目錄結構

整合測試的撰寫

與單元測試的比較

#### 程式碼解析：

整合測試策略的深度探討

隧道視野的陷阱與反思

TDD 與整合測試的實踐順序

介面設計的最佳化實踐

程式碼範例：Quicksort Trait 的實作

內容解密：

更新後的測試程式碼

內容解密：

內建整合測試與外部工具的比較

平台相容性的考量

玄貓 BlackCat

使用 `lazy_static` 初始化全域變數

`lazy_static` 的工作原理