The first is a unit test, whereas the second is an integration test. You'll always want both — unit tests for private internals, and integration tests for testing the API.
-
-
-
Yeah, but where do I draw the line when 99% of the API is public? Do I bother with unit tests for specific testing, or do I try and cover all the code by means of integration tests? What about examples, do they count for coverage, or not? Such are my Monday evening ponderings.
- Još 2 druga odgovora
Novi razgovor -
-
-
As per convention. Unit Tests as #[cfg(test)], integration tests into tests/

-
Mmm, I'm just not sure where to draw the line when 99% of the crate *is* public API.
Kraj razgovora
Novi razgovor -
-
-
For modules where the interface is important, I’d rather keep the test code in separate files. For simple utility functions it doesn’t matter.
-
Yeah, for non-public content, unit tests makes perfect sense; but given 99% of the library is public API, I wonder if it ought to be in tests/*.rs
- Još 1 odgovor
Novi razgovor -
-
-
Both The cfg for unit tests and in the /tests for integration tests
-
When it's a library crate, what counts as integration tests?
- Još 1 odgovor
Novi razgovor -
-
-
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
Have 99% under /tests and 1% that’s not public with you .rs files... If you only need public to test it - that’s great! Having it under tests/ proves you’re only using the public api.
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.