-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Separate tests from code under test in libraries #12393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I don't think this is necessary, and I think there is value to having tests live next to the unit they are testing. Out-of-crate tests are fine too, we can add those separately in src/test/run-pass. |
IMO, the tests should be separate from the code. Oftentimes, the LOC for tests can get larger than the library itself. I like what Go does, where each source file |
/cc @aturon , man of many conventions. |
@dead10ck I think this is good use case for glob imports; just have the test |
Conventions changes go through the RFC process today, and so I'm giving this issue a close. Please open an RFC if you'd like to persue this further. Thanks. |
@steveklabnik Was there ever an RFC? If not, is there now a standard way to separate tests? |
@steveklabnik I am also interested in an answer to this. |
Seeing this popping up now again in my inbox. I never opened an RFC for this and kind of got used to it by now ;) |
I truly believe that giving a better API/Option to write tests outside of the same file would be extremely beneficial for RUST language as whole. It would reduce the barrier for other adopters as well as ensure file size can be kept small without sacrificing on reducing documentation/testing. I really would love if this issue could be reconsidered. |
Has there been any progress on this (RFC)? |
internal: Remove `Interned` usage from nameres collector
fix [`derive_partial_eq_without_eq`] FP on trait projection fixes: rust-lang#9413 rust-lang#9319 --- changelog: fix [`derive_partial_eq_without_eq`] FP on trait projection Well, this is awkward, it works but I don't understand why, why `clippy_utils::ty::implements_trait` couldn't detects the existance of `Eq` trait, even thought it's obviously present in the derive attribute.
The bug reported in #12383 made me aware of the convention that tests in non-std libraries often reside in the same file as the code under test. The privacy issue seen in that bug appears to be an immediate consequence of this convention. The convention also leads to pretty large source files that are imho difficult to handle.
Thus I would like to discuss whether this convention should be changed. To suggest a concrete alternative:
lib.rs
; the test module may have substructure depending on the complexity of the library being testedThe text was updated successfully, but these errors were encountered: