Question for all the @rustlang hackers out there -- Do you prefer #[cfg(test)] stuff in your crate, or code in the tests/*.rs files for testing the majority of your code when your library is almost entirely public API?

Jan 20, 2020 Β· 10:21 PM UTC

13
2
1
14
Replying to @dsilverstone @rustlang
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.
1
5
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
1
1
more replies
Replying to @dsilverstone @rustlang
As per convention. Unit Tests as #[cfg(test)], integration tests into tests/ πŸ™ƒ
2
2
Mmm, I'm just not sure where to draw the line when 99% of the crate *is* public API.
Replying to @dsilverstone @rustlang
Both The cfg for unit tests and in the /tests for integration tests
1
4
When it's a library crate, what counts as integration tests?
2
more replies
Replying to @dsilverstone @rustlang
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.
1
4
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.
2
1
more replies
Replying to @dsilverstone @rustlang
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.
2
Replying to @dsilverstone @rustlang
There's also rustdoc.
Load more