Rust 第18节 软件测试
测试已写的函数
在创建每一个lib crate时,rust都会自动生产一个测试 mod;名字为tests;
tests mod 被属性 #[cfg(test)] 修饰,用于测试;
在mod 内,需要在函数头上加属性 #[test]进行修饰,让其变为测试函数
rust
pub fn add(left: usize, right: usize) -> usize {
left + right
}
mod tests {
use super::*;
#[test]
fn test1() {
let result = add(2, 2);
assert_eq!(result, 4);
}
}
进行测试
运行 cargo test 命令运行所有的测试函数;
当使用 cargo test 命令时,Rust会构建一个 Test Runner 可执行文件,他会运行标注了 test 的 函数,并报告其运行是否成功。
主线程监视每一个测试函数的返回结果,如果报错,就认为测试失败
在创建库项目时,会自动创建测试函数 ;创建库项目命令: cargo new name --lib
assert!()、assert_eq!() 和 assert_nq!() 宏
断言 宏 ; assert!(); 检查状态是否为 true ;
true 测试通过;否则,调用 painc! 测试失败
assert_eq!() 判断两个数是否相等
assert_ne!() 判断两个数是不是不等
这两个宏,当断言失败时都会打出两个参数的值;
这三个宏都可以添加自定义信息,当出错时会打印出来;在固定的参数后边,有一个自定义参数
rust
#[test]
fn test_eque() {
assert!(my_eque(12, 10),"结果不对");
}
#[test]
fn add_two_test()
{
assert_eq!(4,add_two(2));
}
#[test]
fn add_two_test_v2()
{
assert_ne!(5,add_two(2));
}
对于panic进行测试
在特定情况下测试是否会发生panic
加属性 should_panic;如果发生painc ,测试通过,没有发生painc,测试不通过
rust
pub fn get_value(value : i32) -> i32 {
if value > 500 {
panic!("数据过大");
}
value
}
...
#[test]
#[should_panic]
fn get_value_test() {
get_value(1000);
}
...
让 should_panic 更加精准;
单纯的should_panic 只能检测是否发生 panic;但是不确定是否为我们期待的painc;
可以加上 expected ,跟上字符串;进行panic 匹配
rust
pub fn value_config(value : i32) {
if value > 100 {
panic!("value is more 100");
}
if value < 0 {
panic!("value is less 0");
}
}
...
#[test]
#[should_panic(expected = "value is more 100")]
fn value_config_test() {
value_config(120);
}
...
Result 作为测试结果
除了让测试程序painc;还可以通过测试函数的返回值来进行判断测试结果。
需要测试函数的返回值为Restul类型;
返回Ok;测试通过; 返回Err();测试不通过
rust
#[test]
fn test_result() -> Result<(),String> {
if 2 + 2 == 4 {
Ok(())
} else {
Err("测试执行失败".to_string())
}
}
cargo test 命令
当cargo test 不加参数时,会进行默认行为:
1、并行运行
2、所有测试
3、正常时捕获(屏蔽)所有输出;异常时才会显示
它的参数
分为
1) cargo test的参数
2) cargo test -- 的参数;--后的参数,后边有空格;是给测试生成的二进制文件用的
cargo test --help; 显示1 可用参数
cargo test -- --help 显示 --后可用参数
并行测试时,需要保证测试项之间没有依赖,且没用共用的全局变量或环境变量等;
指定并行线程个数 cargo test -- --test-threads=1
显示函数执行时的输出
cargo test -- --show-output
按测试的名称运行测试
单个测试
cargo test 测试函数名
参数只能传一个
多个测试
参数写 测试名的一部分 或者模块名
忽略某个测试项
测试项加属性 ignore
默认运行cargo test 时,就不会运行该测试项;
也可以单独运行 ignore 类型的测试项
cargo test -- --ignored
rust
#[test]
#[ignore]
fn test_ignore() {
assert_eq!(10,100);
}
测试的分类
1) 单元测试
上边均为集成测试的例子
小,专注某一段代码;对某一段代码进行隔离测试
一般在代码相同路径,建立 tests 模块;并加属性标注 #[cfg(test)]
这样只有在执行cargo test 时才会编译和运行代码;而一般的cargo run 不会进行编译运行
单元测试可以测试私有函数
rust
fn fun_2(a : i32,b : i32) -> i32 {
a + b
}// 私有函数
#[test]
fn test_p() {
assert_eq!(2,fun_2(1, 1));
}
2) 集成测试
测试代码不在同一路径下,不用属性标注 #[cfg(test)]
完全位于被测试库外边
只能调用测试库的外部接口
创建tests目录
每一个单独的测试文件都是一个单独的crate
rust
use adder; //导入要测试的lib
#[test]
fn test_v1() {
assert_eq!(4,adder::add(2, 2));
}
tests 目录会被单独处理;
只有运行cargo test 时,才会编译运行
运行指定的集成测试; cargo test 函数名
运行某个文件下所有集成测试 cargo test --test 文件名
由于每个文件都被作为单独的crate,所以各个文件之间数据不共享;
如果想用不被当做单独的crate进行测试,只需要再建一个目录,然后在该目录下新建文件即可;
新的子目录不会被rust当做测试的crate,不会在 cargo test 中调用;
单元测试的crate都可以访问这个文件;作为数据共享
binary crate 的集成测试
如果只有 src/main.rs;没有 src/lib.rs
则,不能在tests下创建集成测试;
无法将main.rs 中的函数导入作用域
只有 library crate 才能暴露函数给其他crate用
binary crate 意味着独立运行