0

I'm building a crate for reading and writing a file format. Reading is accomplished via nom parser-combinators. As a result I have lots of small parser methods like:

named!(read_prop_fs<&[u8], PropChunk>, do_parse!(
    tag!("FS  ") >>
    size: be_u64 >>
    fs: be_u32   >>
    (PropChunk { id: PropId::FS(fs), size: size })
));

The parser functions are in io::input::internal and are all private. Most of the data types they use are also private to that module.

The file writer code I would like to test is in io::output::internal. Ideally, I would like to use the parser functions in unit tests for the writer.

Making all these methods and types pub or even crate seems very ugly. It seems equally strange to invert the modules, having the equivalent of io::internal::{input, output} where input and output are ultimately pub and represent the crate API.

Is there a way to do something like this?

When #[cfg(test)] is true the default visibility in the current module should be crate, otherwise the default should be private.

If not, is there a typical, ergonomic workaround?

Tim
  • 4,560
  • 2
  • 40
  • 64
  • 1
    I believe your question is answered by the answers of [What is the idiomatic way to have a private function tested?](https://stackoverflow.com/q/31752882/155423). If you disagree, please [edit] your question to explain the differences. Otherwise, we can mark this question as already answered. – Shepmaster Aug 16 '18 at 20:27
  • Otherwise, it's answered by the answers of [How do I change a function's qualifiers via conditional compilation?](https://stackoverflow.com/q/49479854/155423). – Shepmaster Aug 16 '18 at 20:33
  • Yes, the conditional compilation macros are probably the closest to what I want. – Tim Aug 16 '18 at 20:35

0 Answers0