#测试执行器 #执行器 #集成 #回归 #集成测试 #测试

kevlar

A simple Test Harness for writing integration / regression tests in Rust

3 个版本

0.1.2 2019年11月26日
0.1.1 2019年11月25日
0.1.0 2019年11月24日

#540 in 测试

MIT 许可证

25KB
321

凯夫拉尔测试执行器

A test harness for writing full-featured integration / regression tests in Rust.

它的主要目标是提供所有基本测试执行器功能以启动测试用例,这样你就可以专注于编写测试。

这包括

  • 日志记录(已经使用为测试创建的唯一工作空间目录设置好了)
  • 配置参数
  • 设置测试工作空间目录
  • 管理工件(提供将工件附加到测试结果的方法)
  • 轻松提交测试结果到外部 webhook
  • 从错误返回值推导测试状态代码
  • 有用的实用工具

注意 此项目是 WIP 且尚未准备用于生产。

难道 Rust 已经通过 "cargo test" 支持自动化测试了吗?

是的,它支持。然而,此 crate 不打算取代这些类型的测试。对于单元测试和代码的小型、快速测试,你应该继续使用 Rust 内置的测试功能(请参阅官方文档此处)。

此 crate 旨在进行更大规模的测试,特别是集成测试,例如使用 Selenium 测试 Web 应用程序,或测试其他软件甚至硬件平台。使用它为单独的软件或硬件应用程序创建一个健壮的测试套件。

而不是花时间编写提供日志记录和测试结果捕获等功能的样板代码,此 crate 允许你专注于编写测试代码和相关抽象。

示例使用

注意 它仍然是 WIP。

在接下来的几周/几个月内,我将对这个语法进行大量实验,直到我想出一些感觉在规模上更舒适的写法。

支持同步和异步测试。

use kevlar::*;
use std::path::PathBuf;
use async_trait::async_trait;
use log::*;

#[tokio::main]
async fn main() {
    let harness = TestHarness::new(
        "kevlar_example",
        ConfigType::File(PathBuf::from("./config.json")),
    );
    harness.run_async::<MyTest>().await;
}

#[derive(Default)]
struct MyTest;

#[async_trait]
impl AsyncTestCase for MyTest {
    async fn run_async(&mut self, _test_config: TestConfig, _test_result: &mut TestRecord) -> TestResult {
        info!("Do something interesting");
        Err(TestEvent::new(TestStatus::Failed).with_description("Something went wrong"))
    }
}

现在 config.json 文件只需要指定路径

{"path": "/tmp/kevlar-tests/"}

启动单个测试

通常,自动化测试框架通过命令行界面(CLI)指定测试名称来启动测试,然后动态加载相应的模块,并在其中即时实例化测试对象。

Rust是一种静态类型语言,没有像Python那样的反射或动态加载功能。最接近的等价物是动态链接库(DLL)。

但是,加载动态模块意味着模块本身需要包含大量的模板代码,以便暴露C风格的FFI。你最终会添加复杂性(更不用说几个“不安全”块),基本上只是为了避免在每个测试中包含测试框架设置代码。但这只有在你的测试框架非常大时才有意义。

该crate提出的解决方案是提供轻量级的测试框架作为附加组件,你可以通过几行代码启动测试。之后,你的测试就变成了简单的二进制文件,可以直接从命令行运行。

我对在测试框架中也提供基本的CLI选项解析功能很感兴趣。然而,提供自定义选项给测试的主要方式将是通过config.json文件或环境变量。

另一个感兴趣的问题是如何将测试分组成套件,以便它们可以一起运行。我一直更喜欢将测试框架和测试运行器基础设施分开,这样并行化和管理测试运行的任务就超出了测试框架本身的范围。

Rust允许crates构建多个二进制文件,这可能是一个选项,可以将多个测试放在同一个crate中。否则,每个测试都需要自己的crate,并且需要独立构建。这并不那么糟糕,但它确实会增加你的构建系统的复杂性。任何复杂性减少都是好的,所以我将研究简化这一点的途径。

在可预见的未来,这个crate应被视为实验性的,并且后续版本很可能包含破坏性更改。

稳定性计划从v1.0开始。在此之前,请期待出现错误。

依赖项

~4–6MB
~106K SLoC