仅针对跨多个 crate 的测试实现特征的惯用方法是什么？ [复制]答案

【问题标题】：What is an idiomatic way to implement a trait only for tests across multiple crates? [duplicate]仅针对跨多个 crate 的测试实现特征的惯用方法是什么？ [复制]
【发布时间】：2021-04-02 23:34:20
【问题描述】：

我在一个有几十个板条箱的工作区工作。其中一个板条箱暴露了一个特征。作为一个模拟，我在每个函数中使用unimplemented! 为() 实现该特征（它们实际上并未使用）。我希望其他 crate 可以使用该实现，但仅限于测试期间：这样做的惯用方式（最方便）是什么？

目前，该实现在 mock 功能之后，我将这个带有 mock 功能的 crate 添加为随机 crate 中的开发依赖项。这迫使编译器在测试期间考虑该实现。这是一个丑陋的黑客，所以我宁愿有另一种方式。

【问题讨论】：

为什么不在测试箱中为在同一个测试箱中定义的类型struct Dummy;而不是()实现特征？
看来What is an idiomatic way to have shared utility functions for integration tests and benchmarks? 的答案可能会回答您的问题。如果没有，请edit您的问题来解释差异。否则，我们可以将此问题标记为已回答。
@Shepmaster 我会为实用程序创建一个板条箱，比如一些函数，但对于 trait 实现来说会有点奇怪
@Boiethios 该帖子有三个单独的答案。

标签： testing rust

【解决方案1】：

使用test 门控的项目不会从板条箱中导出，即使对于将其用作开发依赖项的板条箱也是如此。

As of Rust 1.51.0，您可以使用自定义功能解决这个问题。

在Cargo.toml:

[features]
test-traits = []

在代码中：

#[cfg(feature = "test-traits")]
impl MyTrait for MyStruct {}

在依赖它的 crates 中，您可以启用新的解析器：

[package]
resolver = "2"

并添加一个启用该功能的开发依赖项：

[dev-dependencies]
your_crate = { version = "1.0", features = ["test-traits"] }

如果不启用新的解析器，所有功能都会跨目标添加，因此启用dev-dependencies 中的功能也可以为非测试代码启用它。使用新的解析器，现在的处理方式更符合您的预期。

【讨论】：

很抱歉给您带来了困惑。我已经修改了我的问题，所以它更清楚
@Boiethios 我更新了答案，但我没有看到你的问题更新。我认为这是目前最好的选择。
@Shepmaster 是的。我会更新以添加它。