You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 12, 2021. It is now read-only.
I’m not sure I completely follow the trickiness with #[test] and #[ignore] orderings, but it seems to me like we could make both of them procedural macros in the prelude by default perhaps? If both #[test] and #[ignore] were routed to the same procedural macro, it wouldn’t matter which runs first and #[ignore] would just otherwise verify that #[test] exists (removing it).
In the meantime there are also a couple of things that we might want to do, but that's probably better to discuss them in their own issues:
refactor argument parsing, formatting, json, etc. to make them reusable for other custom test frameworks
refactor testing and benchmarking into different crates, so that one doesn't need to pull in the whole testing infrastructure for benchmarks and vice-versa
use the real term crate instead of our own fork
make sure that libtest is usable as a custom_test_framework (and potentially "libbench" as well if we have splitted them in two)
We should come up with a couple of goals for the roadmap of what to do next. The first goal is probably making the crate usable. For that we need to:
To get it running on stable Rust we can just try to stop using unstable Rust features. To get rust-lang/rust to use it, the main blocker was the relationship between
#[ignore]
and#[test]
which was discussed in the internal thread (https://internals.rust-lang.org/t/a-path-forward-towards-re-usable-libtest-functionality-custom-test-frameworks-and-a-stable-bench-macro/9139).@alexcrichton proposed the following:
In the meantime there are also a couple of things that we might want to do, but that's probably better to discuss them in their own issues:
term
crate instead of our own forklibtest
is usable as acustom_test_framework
(and potentially "libbench
" as well if we have splitted them in two)cc @djrenren
The text was updated successfully, but these errors were encountered: