> 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

> 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

edit: add citation, info, times, link, will -> might, and formatting.