Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async tests #19

Open
mackwic opened this issue Jul 23, 2016 · 9 comments
Open

Async tests #19

mackwic opened this issue Jul 23, 2016 · 9 comments

Comments

@mackwic
Copy link
Member

mackwic commented Jul 23, 2016

I don't know. But we should think of it.

Ideas:

  • a callback injected by argument in the test ? we may be able to use generic on closure to detect that the test needs this argument ?
  • a test_running instance created via another method ? Using signaling ? I dunno
  • Be pragmatic and have an optional module which is specific to MIO
@mackwic
Copy link
Member Author

mackwic commented Aug 17, 2017

Well, thanks to the glorious Rust community, we have only one type for async.

So it's just a matter of Implementing ExampleResult for Future, and executing the future synchronously when resolving the result.

It's not true async, but the runner don't support parallelism for now, so it's all we can do and it seems good enough for now.

@regexident
Copy link
Collaborator

Once #30 (parallelization) gets merged this should be feasible. 💪

@regexident
Copy link
Collaborator

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" to do async testing (via .await(), e.g.) and my gut tells me that async matching might make for a great micro-crate on its own, disconnected from rspec. This would bring convenience APIs for async testing not only to rspec, but also rust's native tests, e.g.

Would you agree, @mackwic?

@mackwic
Copy link
Member Author

mackwic commented Aug 22, 2017

Well, now that I think of it, a test could have multiple assertions.
We can't resolve the Futures from ExampleResult because there is only one return value (which will be resolved) and the other will be let appart...

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 the stabilization of rspec.

I don't like the idea of a separated, async version of it anyway. That's ugly.

@mackwic
Copy link
Member Author

mackwic commented Aug 22, 2017

I'll make an organization, so that we can mutualize crates easily.

@regexident
Copy link
Collaborator

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 the stabilization of rspec.

I agree.

I'll make an organization, so that we can mutualize crates easily.

I saw it, that's great!

@cataggar
Copy link

cataggar commented Sep 9, 2022

Rust async has come a long way in the last 5 years. Is it possible to use with this project?

@mackwic
Copy link
Member Author

mackwic commented Sep 9, 2022 via email

@vittorius
Copy link

Hey. Are there any plans regarding this library feature? Or any vision in general?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants