#fail #run-time #conditionally #another #error #points

failpoints

Failpoints for rust. Another fail-rs.

2 个不稳定版本

0.2.0 2022年1月17日
0.1.0 2021年5月24日

#402 in 测试

Download history 4/week @ 2024-02-26 21/week @ 2024-03-18 18/week @ 2024-03-25 40/week @ 2024-04-01 14/week @ 2024-04-22 25/week @ 2024-05-20 19/week @ 2024-06-03 38/week @ 2024-06-10

每月82次下载

Apache-2.0 OR MIT

40KB
579

failpoints, another fail-rs

CI Crates.io

文档.

为 Rust 实现的故障点。

故障点是代码植入,允许在运行时动态注入错误和其他行为,主要用于测试目的。故障点具有灵活性,可以配置以展示各种行为,包括恐慌、提前返回和睡眠。它们可以通过程序和环境进行控制,并且可以条件性和概率性地触发。

此软件包受 FreeBSD 的 故障点 的启发。

用法

首先,将以下内容添加到您的 Cargo.toml

[dependencies]
failpoints = "0.1"

现在您可以从 failpoints 软件包中导入 failpoint! 宏,并使用它来注入动态故障。默认情况下,此宏禁用故障点生成,可以通过 failpoints Cargo 功能在相关位置启用。

以下是一个示例程序,它使用故障点来模拟 I/O 潘恐慌

use failpoints::{failpoint, FailScenario};

fn do_fallible_work() {
    failpoint!("read-dir");
    let _dir: Vec<_> = std::fs::read_dir(".").unwrap().collect();
    // ... do some work on the directory ...
}

fn main() {
    let scenario = FailScenario::setup();
    do_fallible_work();
    scenario.teardown();
    println!("done");
}

在此,程序在 read_dir 的结果上调用 unwrap,这是一个返回 Result 的函数。换句话说,这个特定的程序期望 read_dir 总是成功。在实践中,这几乎总是如此,这使得在 read_dir 失败时测试此程序的行为变得困难。通过使用故障点对程序进行植入,我们可以假装 read_dir 失败,导致后续的 unwrap 潘恐慌,并允许我们在故障条件下观察程序的行为。

程序正常运行时,只打印 "完成"

$ cargo run
     Finished dev [unoptimized + debuginfo] target(s) in 1.18s
     Running `target/debug/failpoint`
done

但现在,通过设置 FAILPOINTS 变量,我们可以看到如果 read_dir 失败会发生什么

$ FAILPOINTS=read-dir=panic cargo run --features failpoints/failpoints
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/failpoint`
thread 'main' panicked at 'failpoint read-dir panic', /home/psiace/Projects/ritelabs/dev/failpoints/src/lib.rs:498:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

有关更多信息,请参阅 API 文档.

依赖项

~1–1.6MB
~24K SLoC