Vincent Esche

@Lukas-Stuehrk I 100% agree with you. The fix we went for (for now) was something we could do "today". It's far from good, but it at least allows you to...

We already have 3 × 3 functions for creating suites/contexts/examples. Any further addition of skipping variants (9 more functions each!) would be a bad idea, imho. Instead we should [consider...

Problem I see with this is that we support several different sources: - `Result` - `Bool` - `()` - `panic!()` - [expectest](https://github.com/zummenix/expectest)'s own `Result` The problem is with the last...

I agree. :) Rust's `assert_eq!` and `assert_ne!` however both panic. As such one couldn't do any of the above (screenshot) without some kind of parsing of the returned string. Or...

This being said I think in the long run we need to improve Rust's testing API instead of trying to shoehorn our far more expressive API into it. These hacks...

Btw, both of these stats are already collected during test execution. As such `SuiteReport`, `ContextReport` & `ExampleReport` already provide: - their respective execution time - `succeeded`, `failed` or `ignored` We...

I'll look into it when I find some time, thanks!

Once https://github.com/mackwic/rspec/pull/30 (parallelization) gets merged this should be feasible. 💪

Given that with #30 we'd have parallelization I'm wondering if rspec itself should have async-awareness at all. The futures crate provides ["all the pieces"](https://tokio.rs/docs/getting-started/futures/#adding-a-timeout) to do async testing (via `.await()`,...

> So, yes. Async asserts may be the way to go. The other advantage I see in an external crate is to limit the scope and keep experimenting without troubling...