Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
381 views
in Technique[技术] by (71.8m points)

module - Can I make an object public for integration tests and/or benchmarks only?

As suggested by The Book, I have moved the integration tests in my crate to a tests directory. Some of those tests use functions that I don't want to export outside of the crate, though, and I am no longer able to use them in the integration test folder. I use them for non-test purposes too, so they need to compile outside of tests too. I tried using variants of pub(restricted), but I wasn't able to make it work. Ideally I'd like to have something like pub(tests).

directory tree (the relevant bits):

my_crate
|- src
   |- parser.rs
|- tests
   |- parsing.rs
|- benches
   |- parsing.rs

tests/parsing.rs:

extern crate my_crate;

use my_crate::parser::foo;

#[test]
fn temp() {
    foo();
}

benches/parsing.rs:

#![feature(test)]
extern crate test;
extern crate my_crate;

use test::Bencher;
use my_crate::parser::foo;

#[bench]
fn temp(b: &mut Bencher) {
    b.iter(|| { foo(); });
}

My current workaround is to make the relevant objects public and invisible in the docs (#[doc(hidden)]), but it doesn't convey the proper intention. Can I make an object public only for integration test / benchmarking purposes?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

One difference between integration tests and unit tests is that integration tests is supposed to test the "public API" of your crate only. Tests for internal functions is fine to keep together with the functions themselves in the src tree.

If you want to keep them a little separate, you can use a test submodule to the module containing the functions to test, as private parts are available to submodules.

If you still really want to have internal / unit tests in the tests in the tests directory, you can use a feature flag to enable public wrappers of internal functions to test (and mark the tests with the same feature flag). Something like this in the code:

#[cfg(feature = "testable_privates")]
pub fn exposed_something(args) {
    something_private(args)
}

Then in your test methods, you can import and call exposed_something. If the feature testable_privates is not defined, your tests will fail to compile. To solve that, use the feature flag to make the tests conditional as well;

#[cfg(feature = "testable_privates")]
#[test]
fn test_something() {
    assert_eq!(exposed_something(my_args), expected_result)
}

Also, before doing that you need to define the feature in your Cargo.toml, like so:

[features]
testable_privates = []

(The empty array is to signify that the feature does not require any otherwise optional dependencies).

Now, if you just run cargo test, both exposed_something and test_something will just be silently ignored, but if you run cargo test --features testable_privates, they will be compiled and tested.

As you see, this gets rather complicated, so I really think it is a better idea to just test public aspects of your crates from tests and keep tests of private methods close to those methods themselves in src.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...