rain 🌦️
if you use #nextest, I'd really love it if you tried out cargo-nextest 0.9.95-rc.2 -- there are some changes to the way test failures are output that I'd love feedback on:
cargo nextest self update --force --version 0.9.95-rc.2
Thanks!
#nextest 0.9.91 now lets you set test priorities: reorder tests so that they run before or after all others.
To update, run `cargo nextest self update`, or wait for your package manager to update it!
Did you know that #nextest has an expression language to select subsets of tests? https://nexte.st/book/filter-expressions.html
One of the more interesting predicates is `rdeps`, which stands for reverse dependencies of a crate. (The name is inspired by Bazel and Buck.) Why might that be useful? For example, consider nextest's support for setup scripts: https://nexte.st/book/setup-scripts.html
It's common to say "set up a db for tests that depend on any crate that could use the db handling code", and that's exactly what rdeps does.
Just released a new version of cargo-nextest, with a new headline feature: the ability to say what version of #nextest your project or tool needs, or recommends.
(Won't work with older versions, but will work going forward!)
Part of this is also to inspire other tools to put in similar features!
Looks like Chromium's crosvm (https://chromium.googlesource.com/chromiumos/platform/crosvm) just added support for running tests via #nextest! Using nextest's build reuse functionality, they were able to achieve 6-7x faster test runs.
https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4144641?tab=comments
In the post I show how async #RustLang solves practical select problems in #Nextest, and does so in a deeply principled, composable manner. I'm really proud of it because I've taken a view that has been talked about in 1:1 messages and discussions in the past, but hasn't really been written down like this before to the best of my knowledge.
Reupping a post I wrote a few months ago: How and why #Nextest uses #RustLang #Tokio.
This post delves right into the heart of why async Rust exists: to perform *heterogenous selects*. Previous explanations have always been a bit unsatisfying for me. It's more efficient than OS threads, but is that really it? In reality, async Rust satisfies a fundamental need that no other paradigm does, which is to use tokio::select! across arbitrary async sources and platforms.
Would you find setup and teardown scripts useful for #rustlang #nextest test runs? Please upvote and comment in this issue with your use cases! Contributions and design suggestions would be welcome as well, especially if you've had practical experience with setup and teardown scripts for (e.g.) integration tests.
Please boost for reach!
One of the ways I disagree with many of my esteemed fellow Rust people is that I think #async #RustLang is great. Switching #nextest over to #asynchronous Rust has yielded incredible dividends, including but not limited to what I described in https://sunshowers.io/posts/nextest-and-tokio/.
The ability to write cross-platform heterogenous selects provides an extraordinary amount of power.
BTW, now that I'm at @oxidecomputer, I've been trying out nextest on #illumos and it works with zero (0) code changes!