我想写一个单元测试，断言一个方法是私有的。该测试可以看到该方法，并且可以执行和测试它
我想要的附加测试是为了确认该方法仍然是私有的，即，如果未来的编码器(或我自己("；意外地"；将可见性更改为pub。公开该方法会破坏设计，因为它会允许实现的客户端以违反设计其余部分所做假设的方式更改结构。
是否有某种类型的反省或反思会允许这样做？
正如评论中所指出的，字段/函数可见性是一个只在编译时存在的概念，因此您需要找到一种方法来测试某些代码无法编译。
文档测试是一个显而易见的工具，但在某种程度上是一个大锤式的解决方案。我建议使用trybuild机箱。我经常看到宏作者使用它，但当你想测试某个东西是否编译时，它通常会很有用。
一个示例用法可能是：
// src/lib.rs (could be anywhere really, it just needs to be a regular #[test] function)
#[cfg(test)]
#[test]
fn ui_tests() {
let t = trybuild::TestCases::new();
t.compile_fail("tests/fail/*.rs");
}
// tests/fail/private_field_access.rs
fn main() {
let my_struct = MyStruct::new();
println!("{}", my_struct.private_field);
}
这将生成一个相应的.stderr文件，您可以将其检查到版本控制中(类似于rustc的"ui"测试(。运行测试时，会编译文件，并将编译器的输出与实际错误进行比较。
这意味着你可以用比简单的二进制"更细粒度的方式捕捉回归；它编译"；检查例如，如果您意外地将私有字段公开，那么由于其他原因(可能它没有实现Display(，上面的测试可能仍然无法编译。trybuild以compile-faildoctests无法捕捉的方式捕捉这些回归。
当需要生成.stderr文件时，可以运行TRYBUILD=overwrite cargo test来覆盖现有文件。
值得一提的是，trybuild测试(如doctest(仅适用于机箱的外部API，而不适用于模块。如果这是一个问题，您可以考虑使用货物工作区和多板条箱设置(还有其他原因可能更可取，例如编译时间(。