cargo-difftests

"疯狂就是一遍又一遍做同样的事情，却期待不同的结果。" — 未知作者。

— 未知作者。

cargo-difftests 是一个用于Rust的选择性重测试框架。简单来说，它是一个工具，使用LLVM覆盖率数据加上一些关于自上次测试运行以来发生了哪些变化的信息，以找出哪些测试最有可能受到这些变化的影响，因此需要重新运行。

其基本假设是，如果过去一个测试通过了，而且自测试运行以来没有修改任何代码，那么测试的结果不会改变。尽管存在一些边缘情况，但这对大多数crate来说通常是正确的。

先决条件

• 夜间Rust。
• cargo-binutils

推荐设置（使用cargo-generate）

cargo install cargo-generate # if you don't have it already

然后只需应用模板

cargo generate dnbln/cargo-difftests

用法

cargo difftests 的简单用法如下（在模板仓库中）

% # collect profiling data
% cargo difftests collect-profiling-data
% touch src/advanced_arithmetic.rs # change mtime
% cargo difftests analyze --dir target/tmp/difftests/tests/test_add
clean
% cargo difftests analyze --dir target/tmp/difftests/tests/test_mul
dirty
% cargo difftests analyze --dir target/tmp/difftests/tests/test_div
dirty
% cargo difftests collect-profiling-data --filter test_mul --exact
% cargo difftests analyze --dir target/tmp/difftests/tests/test_mul
clean
% cargo difftests analyze --dir target/tmp/difftests/tests/test_div
dirty
% cargo difftests collect-profiling-data --filter test_div --exact
% cargo difftests analyze --dir target/tmp/difftests/tests/test_div
clean

如您所见，它相当详细，但有一个命令可以简化操作：rerun-dirty-from-index。这个命令从一个存储了一些索引的目录中获取，分析每个索引，然后重新运行被认为是脏的测试。

可能的工作流程如下

# initial profiling data collection
cargo difftests collect-profiling-data --compile-index --index-root=difftests-index-root --root=target/tmp/difftests

# modify some files
touch src/lib.rs

# analyze and rerun tests, then recompile indexes
CARGO_DIFFTESTS_EXTRA_ARGS='--compile-index,--index-root=difftests-index-root,--root=target/tmp/difftests' cargo difftests rerun-dirty-from-indexes --index-root=difftests-index-root

这将最初收集所有测试的配置文件数据，然后编译一些索引到 difftests-index-root 目录，然后在某些更改发生后，rerun-dirty-from-indexes 命令将重新运行脏测试，并从相同目录中的新数据中编译新的索引。

这是使用 cargo-difftests 的推荐工作流程。您可能希望为这些命令创建一些别名，或将它们放入shell文件中以便更容易使用。

cargo-difftests

所有测试运行完毕后，需要对性能数据进行分析，并检查包含运行代码的文件自上次测试运行以来是否已修改。如果测试中使用的代码自上次运行以来已修改，则我们认为测试“已污染”，应重新运行以确认更改后它仍然通过。

所有这些分析都在这个包中完成。

简单来说，cargo-difftests会查看测试“接触”到的文件，即在执行过程中，给定文件中至少有一行代码被执行。如果这些文件中的任何文件已修改，则将其标记为已污染，并输出相应的结果。如果没有文件被修改，则重新运行测试可能不会改变结果，因此结论将是测试是干净的。

因此，现在您可以运行测试，可能修改几个文件，然后运行以下命令

cargo difftests analyze-all --dir target/tmp/cargo-difftests # common ancestor of all the difftest directories passed to the testclient init function

这将输出一个JSON数组，其中包含有关测试的信息，以及它们是否需要重新运行（"verdict": "dirty"）。

特性

算法（--algo标志）

有多种方法可以判断文件更改是否会影响测试结果。

fs-mtime

最基本的方法是检查包含执行代码的文件的mtime，将其与我们运行测试的时间进行比较。这在大多数情况下都有效，并且是默认设置。

git-diff-files

基本上与上面的相同，但假设上次完整的测试运行是在最后一次提交（适用于CI），我们比较最后一次提交和当前树的状态之间的树，以检查哪些文件已更改。

也支持与指定的提交进行比较，而不是与最后一次提交进行比较，但应通过--commit选项传递。

注意：在脏工作树上运行测试可能会引起问题。因此，建议仅在CI上使用此选项以快速告知开发人员最可能受影响的测试的结果，但在实际工作时，最好仅使用fs-mtime。

git-diff-hunks

这个扩展了git-diff-files算法，但在这里，我们不是检查文件自上次提交以来是否已接触，而是仅检查文件中修改的特定部分。这是可能的，因为Git实际上为我们跟踪单个行。

与git-diff-files类似，此算法也接受可选的--commit，可以与最后一次提交进行比较。

注意：在脏工作树上运行测试可能会引起问题。因此，建议仅在CI上使用此选项以快速告知开发人员最可能受影响的测试的结果，但在实际工作时，最好仅使用fs-mtime。