My goal is to have unit tests inject a factory trait (called Networker) implementation into my system under test that returns an opaque implementation of AsyncReadExt + AsyncWriteExt + Unpin from its Networker::connect() function such that I can have the same functions I need to call in tokio::net::…

Looking at your main error now... [image] jcreswell-eos: = note: conflicting implementation in crate `tokio`: - impl<W> tokio::io::AsyncWriteExt for W where W: tokio::io::AsyncWrite, W: ?Sized; I think you just need to not implement AsyncWriteExt (and AsyncRe…

I don't know the answer to your main question off-hand, but the last error is [1] due to this change: impl AsyncRead for AsyncReadWriteStream { - fn poll_read( + fn poll_read<'a>( self: Pin<&mut Self>, - cx: &mut std::task::Context<'_>, - buf: &m…

What does blanket implementation mean, exactly? I looked at the AsyncWriteExt source and couldn't find any direct calls to poll_write(), but maybe it's buried in abstraction layers somewhere? If I can mock AsyncRead and AsyncWrite and then in the system under test call the *Ext convenience functions…

Are you aware of tokio_test::io (made by the tokio team), which already provides a mock AsyncRead & AsyncWrite type? [image] jcreswell-eos: What does blanket implementation mean, exactly? A blanket implementation of a trait Foo is an impl<T> Foo for T where T: SomeOtherTrait. In the case of…

In practical terms in means that upstream has provided an implementation that covers downstream types. In this particular case, any implementor of AsyncWrite uses the tokio implementation for AsyncWriteExt: // This is in the `tokio` crate impl<W> tokio::io::AsyncWriteExt for W // <-- It is a "blan…

I took a quick look at tokio_test earlier, but it seems they went a totally different direction with their mock AsyncWrite/AsyncRead -- they let you call read and write functions in arbitrary sequences, but they don't let you install arbitrary read/write behavior as far as I could see (and understan…

In case I wanted to avoid AsyncWrite/AsyncRead conveniences entirely, how would I directly call AsyncRead and AsyncWrite poll_* functions? I'm not sure where the std::task::Context comes from; I know it provides the Waker for a task and somehow comes into being from the dark magics of executors, but…

The only reasonable option I know of is to implement a Future and run it in tokio (eg with .await or block_on()), you will get the runtime's Context. A really easy way to do this is poll_fn

How can I mock tokio::io::AsyncReadExt and AsyncWriteExt traits?

help

quinedot July 16, 2025, 10:05pm 9

That sounds like mocking the executor territory. I'm afraid I'm the wrong person to ask about that.

Is it possible to make mocked AsyncWrite and AsyncRead behavior use tokio::time::sleep() and other async functions?

Topic		Replies	Views
Is it possible to make mocked AsyncWrite and AsyncRead behavior use tokio::time::sleep() and other async functions? help	3	252	July 18, 2025
Unable to find implemented trait help	1	1809	November 19, 2019
Trait that is trivially implemented isn't? help	6	874	March 21, 2020
How to write test async functions without using trait objects help	4	703	February 2, 2024
Fail to implement `AsyncWrite` on a struct which should implement it help	9	1111	September 25, 2022

How can I mock tokio::io::AsyncReadExt and AsyncWriteExt traits?

Related topics