3 个版本
0.1.2 | 2019年11月26日 |
---|---|
0.1.1 | 2019年11月25日 |
0.1.0 | 2019年11月24日 |
#540 in 测试
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