1.摘要

Rust中的測試函數(shù)是用來驗(yàn)證非測試代碼是否是按照期望的方式運(yùn)行的, 測試函數(shù)體通常需要執(zhí)行三種操作:

• 設(shè)置任何所需的數(shù)據(jù)或狀態(tài);
• 運(yùn)行需要測試的代碼;
• 斷言其結(jié)果是我們所期望的。

本篇文章主要探討了Rust自動化測試的幾種常見場景。

2.測試函數(shù)詳解

在Rust項(xiàng)目工程中, 可以對任意函數(shù)進(jìn)行自動化測試, 前提是需要在被測試函數(shù)上面加上#[test]注解, 然后運(yùn)行cargo test命令進(jìn)行函數(shù)自動化測試, Rust會查找所有被#[test]注解的函數(shù)并自動進(jìn)行測試。

先看下面一段代碼:

#[test]
fn add_calc() {
    let result = 1 + 2;
    assert_eq!(result, 3);
}

在上面的代碼中, 我實(shí)現(xiàn)了一個加法計(jì)算的函數(shù): add_calc(), 將加法結(jié)果保存到不可變變量result中, 并使用了assert_eq!宏來斷言1+2的結(jié)果, assert!宏由標(biāo)準(zhǔn)庫提供, 在希望確保測試過程中一些條件為true時非常有用。在函數(shù)上方加上了#[test]注解, 表示該函數(shù)將執(zhí)行自動化測試, 運(yùn)行: cargo test看下結(jié)果:

從測試結(jié)果中, 可以看到test add_calc ... ok 這行, 表示該函數(shù)測試通過了。

現(xiàn)在我修改下斷言的結(jié)果, 將代碼修改為:

#[test]
fn add_calc() {
    let result = 1 + 2;
    assert_eq!(result, 4);
}

再次運(yùn)行cargo test命令, 返回結(jié)果如下:

可以看到, 計(jì)算的結(jié)果是3, 但斷言相等的條件是等于4, 因此函數(shù)執(zhí)行失敗, add_calc()函數(shù)自動化測試不通過。

接下來我們再加入一個函數(shù), 看看在具有多個函數(shù)的前提下, 同時具備成功和失敗的情況, 代碼如下:

#[test]
fn add_calc() {
    let result = 1 + 2;
    assert_eq!(result, 3);
}

#[test]
fn another_method() {
    panic!("執(zhí)行失敗,拋出一個異常!")
}

在上面的代碼中, 增加了一個名為another_method()的函數(shù), 該函數(shù)直接使用panic!拋出一個異常, 直接扮演了函數(shù)執(zhí)行失敗的角色, 而上面的add_calc()函數(shù)我講assert_eq!宏修改正確, 將扮演執(zhí)行成功的角色, 使用cargo test命令看下結(jié)果:

可以看到, add_calc()函數(shù)測試沒問題, 后面用綠色ok表示, 而another_method()函數(shù)執(zhí)行失敗, 使用紅色的FAILED標(biāo)記。

3.自定義失敗信息

在上面的案例中, 我使用了assert_eq!宏來斷言結(jié)果, 同樣, 也可以向宏傳遞一個可選的失敗信息參數(shù), 可以在測試失敗時將自定義的失敗信息一并打印出來, 使用自定義信息有個好處, 當(dāng)測試失敗時, 能更好的理解代碼到底出了什么問題, 看一段下面的代碼:

pub fn make_string(name: &str) -> String {
    format!("Hello,{}!", name)
}

#[test]
fn is_contain_name() {
    let result = make_string("cargo");
    assert!(result.contains("cargo"));
}

在這段代碼中, 定義了一個函數(shù)make_string, 該函數(shù)接收一個字符串參數(shù), 并在函數(shù)內(nèi)部通過format!宏格式化字符串后返回, 在函數(shù)is_contain_name()中, 傳入一個字符串"cargo", assert!會判斷make_string()函數(shù)返回的字符串中是否會包含"cargo"字符串,如果包含就是成功的,否則就失敗, 這里我們能預(yù)言結(jié)果應(yīng)該是成功的, 測試一下看看:

結(jié)果跟我們預(yù)想的一樣, 現(xiàn)在再加入一些更詳細(xì)的變化信息看看, 代碼如下:

pub fn make_string(name: &str) -> String {
    format!("Hello,{}!", name)
}

#[test]
fn is_contain_name() {
    let result = make_string("rustup");
    assert!(result.contains("cargo"), "make_string中不包含該字符串,值為:`{}`", result);
}

我在assert!宏中加入了變量打印, 假如make_string()函數(shù)沒有返回預(yù)期的結(jié)果, 那結(jié)果到底是什么,這里我們將能看到失敗原因, 測試結(jié)果如下:

從結(jié)果可以看到, 函數(shù)的確測試失敗了, 但我們看到了關(guān)鍵信息, 失敗的原因是因?yàn)閙ake_string()函數(shù)返回的字符串內(nèi)容為:Hello,rustup!,這個結(jié)果與斷言中的result.contains("cargo")結(jié)果是不同的, “Hello,rustup!”字符串中并不包含"cargo"字符串,所以函數(shù)測試失敗。

4.檢查崩潰異常

除了使用斷言宏之外, Rust還提供了一個should_panic用來檢測程序中的panic,并且提供了一個名為expected的參數(shù)用來自定義消息,看一段下面的代碼:

pub fn number_calc(value: i32) -> i32 {
    let ret_value = 40;
    if value < 0 {
        panic!("值必須大于0,傳參的值為:{}", value)
    }
    return ret_value
}

#[test]
#[should_panic(expected = "傳參不能小于0")]
fn is_contain_name() {
    let result = number_calc(-1);
}

在number_calc()函數(shù)中, 如果判斷參數(shù)傳入的值小于0, 會拋出一個panic, 為了監(jiān)視是什么原因?qū)е? 在函數(shù)is_contain_name()上面使用should_panic進(jìn)行監(jiān)控, 并使用expected參數(shù)指定自定義消息, 如果遇到傳入的參數(shù)小于0, 將觸發(fā)該消息打印, 使用cargo test運(yùn)行一下看看結(jié)果:

從結(jié)果可以看到, 的確檢測到了panic產(chǎn)生, panic打印了本身的消息, 最后一行shoud_panic也觸發(fā)了消息, 并打印出失敗的原因。

5.使用Result<T, E>測試

先看一段下面的代碼:

pub fn number_calc(value: i32) -> i32 {
    let ret_value = 40;
    if value < 0 {
        return 30
    }
    return ret_value
}

#[test]
fn is_contain_name() -> Result<(), String>{
    if number_calc(2) == 40 {
      OK(())
  }else{
    Err(String::from("結(jié)果不等于40,請檢查原因!"))
  }
}

在上面的代碼中, is_contain_name()函數(shù)的返回類型現(xiàn)在變?yōu)?Result<(), String>, 在函數(shù)體中, 不同于調(diào)用assert_eq!,現(xiàn)在如果測試通過,將返回Ok(()), 在測試失敗時, 返回帶有String的Err錯誤。現(xiàn)在傳入?yún)?shù)為2, 將顯示正常的結(jié)果:

現(xiàn)在我們再傳入一個小于0的負(fù)值看看,結(jié)果如下:

可以看到, 如果使用Result<(), String>接收結(jié)果, 當(dāng)出來錯誤時, 將返回一個Error,并打印對應(yīng)的自定義消息。

6.總結(jié)

在本篇文章中, 我們使用#[test]注解完成了對指定函數(shù)的自動化測試, 使用assert!宏對錯誤進(jìn)行斷言, 在斷言中自定義錯誤顯示消息用于查看更詳細(xì)的錯誤原因。使用了should_panic對panci錯誤進(jìn)行了監(jiān)控, 最后使用Result<T, E>替代斷言分別完成了代碼測試和自定義錯誤消息打印, 在以后的實(shí)際應(yīng)用中, 可能還會有一些組合測試的場景出現(xiàn), 到時候再具體問題具體分析。