These are chat archives for rust-lang/rust

19th
Sep 2018
Timothy Shoaf
@timshoaf
Sep 19 2018 03:10
Here's a question for anyone. How do you all go about organizing your tests. From a standard BDD / TDD in CI/CD setup, one typically has unit, perf, and integ tests. The first gets run for code coverage purposes and implies build failures, the second has metrics around tight loops and may be divided between build failures and promotion failures as actual samples on similar fleets are tested, and then integ tests ostensibly should be run against integ environments for other services etc and fail deployment promotion.
If one has a project divided into several modules under src, how do you go about file organization for unit tests?
Timothy Shoaf
@timshoaf
Sep 19 2018 03:31
Ideally, I'd like to keep my tests as close to my code as possible (have a test file in each module with the source modules). Or, failing that, a unit test directory that mirrors the structure of the source folder.
Is this an anti-pattern in this language? Or is this a doable thing?
James McCoy
@jamessan
Sep 19 2018 03:50
Cargo's project layout and test documentation look like they agree with your preference
Timothy Shoaf
@timshoaf
Sep 19 2018 04:11
@jamessan I guess my only issue with the example is that it doesn't delve into the general structuring philsophy with respect to dealing with nested modules
if I have a common/{mod.rs, some_asinine_example.rs}, with common/utils/{mod.rs, some_asinine_example.rs}; it is tempting to do a common/test/some_asinie_example/{mod.rs some_assinine_example.rs} to keep the tests direclty next to the code and so that the test runner outputs ``running n tests:
Timothy Shoaf
@timshoaf
Sep 19 2018 04:17
running n tests
test common::test::some_asinine_example::it_does_one_asinine_thing_the_way_its_supposed_to ... ok
test common::test::some_asinine_example::it_does_another_asinine_thing_the_way_its_supposed_to ... failed!
but I am not sure if that is a particularly offensive directory structure for some reason outside of the necessity to do one incredibly silly: use super::super::super::some_asinine_example::ThingImTesting
which I suppose I could get rid of by importing one super level at a time as I declared the modules to bring it into scope, but leaves the side effect of having to edit more than just a test file and the implementation files anytime I want to test a new piece of code
So I figured I'd ask about to see how other people like to structure their projects
Or if, like python / java etc, third party testing suites have begun to dominate?
Lyle Mantooth
@IslandUsurper
Sep 19 2018 12:51
@timshoaf, most of the unit test examples I have seen are actually a mod test {} in the same file as the stuff it tests. They nearly all have use super::*; in them to bring the module under test into scope.
I would argue that common/test/example/asinine_example.rs is actually far from common/utils/example/asinine_example.rs since their common (heh) ancestor is so far up the directory tree.
Ichoran
@Ichoran
Sep 19 2018 18:47
That's the idiom I mostly follow also.
Karrq
@LandKingdom
Sep 19 2018 20:50
I do the same too
//say this is our crate (gitter-rs)
#[cfg(test)]
mod test;

// -- rest of the code inside gitter-rs module --
The directory structure would look like this:
gitter-rs -\
| - src -\
| - lib.rs
| - test.rs
ofc formatting of the directory structure broke
well: gitter-rs/src/{lib.rs, test.rs}