3 ms·
> Every file in the tests directory is a separate crate, compiled to its own executable. This is a reasonable decision, with undesirable consequences: Other pr
by epage 5y ago
> Every file in the tests directory is a separate crate, compiled to its own executable. This is a reasonable decision, with undesirable consequences:
Other problems with this:
- You have to link each test file which can be slow
- You get less parallel test running because you've broken things up into smaller parallel batches. cargo-nextest is a proof-of-concept that shows this problem [0]
- Fixture initialization reuse becomes trickier
Projects like cargo explicitly combine all integration tests into a single binary. I'd love it if we explored implicitly rolling everything up into a single test binary except for any explicit test targets defined by the user.
[0] https://nexte.st/book/benchmarks.html https://nexte.st/book/benchmarks.html
- scns 5y ago> You have to link each test file which can be slow Using Mold [0] as the linker might help. Written by the author of lld. Program (linker output size): GNU gold | LLVM lld | mold Chrome 96 (1.89 GiB): 53.86s | 11.74s | 2.21s Clang 13 (3.18 GiB): 64.12s | 5.82s | 2.90s Firefox 89 libxul (1.64 GiB): 32.95s | 6.80s | 1.42s [0] https://github.com/rui314/mold https://github.com/rui314/mold edit: add citation, info, times, link, will -> might, and formatting.
- tlamponi 5y agoFWIW, I tried it on a rust project here, the difference was in the noise range only; that way I knew that I was rather IO limited (linking produces lots of IO) and also that mold benchmarks _may_ potentially overpromise a bit much, at least when applied at my use case.