I just wanted to encourage that tests are split off into their own directories.
So, what we would see, for each crate, becomes:
├── src
│ └── lib.rs
└── tests
└── tests.rs
Perhaps that is a trick that’s already understood? I note there is that directory structure in self_encryption but then the src code still retains most of the testing.
I wonder that splitting the main code from the tests, would make the code base less intimidating to us noobs. For example, a simple grep for fn calls atm pulls all the tests detail too; everything else is twice+ the codebase too… self_encryption/src/lib.rs would fall from 1042 lines to 547, etc
This change I’m expecting is trivial to action and would be a route to making the code a lot simpler to understand. I do not know, whether this has implications for how tests are run at compile and if those happen in the same way or need to be encouraged with cargo test but still, I expect it’s worth that difference.
I think, but am not a Rust export, that embedding tests in the source is a Rust convention. As with documentation, including sample code, being embedded in the source means everything is in one place, all validated by the compiler, and every Rust program will have the same organisation.
I haven’t done enough to say I think this is overall better than splitting things up, but my first impression is I like it. Why do you think splitting would make it easier for Rust n00bs like us?
I just found http://exercism.io/ rust exercises, which look to be a good test driven route to learning rust.
Seeing they way that core code stands alone, just looks so much tidier.
I’ve also been pulling the detail from the SAFE src to see what’s there and greps pull all the additional detail from test; so, all the test functions, that are not obviously named as test_functions, only add to my confusion. I’m doing that in an effort to make sense of the way the elements of code relate to one another.
I note that if tests are split into /tests/ those are not run by cargo build and need cargo test.
So, I expect that the tests within self_encryption/tests/lib.rs are not being used as often as the ones in the /src/lib.rs
Trivially, I wonder that it would make compilation quicker where testing not required… not that it’s an issue for most users but if there were tests that took time then perhaps it’s worth the difference.
Put it down to my OCD, if you want. Obviously, devs’ needs comes first.
1 Like
The way we work this in house is that in source tests (i.e. unit tests, possibly behavioural testing as well) include testing non public data.
The tests in /tests/ are integration tests, i.e. these have only public access to methods and data (kind like a user would get). These are called integration tests.
Then we have the examples, where we put example use of the library (not tests) which is really a nice way to confirm it does at should, like Self Encryption it’s great to let folks run the code against lots of different files on lots of different OS’s etc.
3 Likes
I’m not sure I understand the difference but I am noob…
I wonder the /tests/ have access to non public functions; that is, they run as if they were in the /src/
If what you’re suggesting is just devs preference for the way tests are run, that’s obviously fine too.