The book (here: Test Organization - The Rust Programming Language suggests the convention is to put the unit tests in the same file as the source code in a mod to keep tests close to the code:

[#cfg(test)]
mod test {...}

It seems ok for trivial/toy code. However, for real life code (with large files and complex folder structures), it makes source files quite large doubling or tripling the lines of code and makes it hard to navigate and look at test and code side by side (at least for me). Also, it makes it difficult to understand production and test code's dependencies on use of crates.

In other languages (from my experience esp. C++ and Python) the usual convention is to separate production and test code in separate files (and a few conventions around the folder structure, typically some flavour of these 2 structures:

            Option 1                     | Option 2
src                                      | src
+- lib1                                  | +- lib1
   +- code (files/folder)                |    +- code (files/folders)
   +- tests (files/folder)               | +- bin1 
      +- unit (files/folder)             |     +- code (files/folders)
      +- integration (files/folder)      | tests
+- bin1                                  | +- unit
   +- code (files/folder)                |    +- lib1 (files/folders)
   +- tests (file/folder)                |    +- bin1 (files/foldres)
      +- unit (files/folder)             | +- integration
      +- integration (files/folder)      |    +- (files/folders)

I'd love to learn what conventions do people follow in real-world large-scale Rust projects that have large code base, with long source files, and a complex package/workspace structure. thanks

2 posts - 2 participants

Read full topic