Add tests for async_channel

[amab8901]

addresses 3rd checkbox in #715

Let me know if I did it correctly and if there's anything missing

[kevinaboos]

Thanks! The initial set of tests is decent, but there are a few more scenarios that ought to be tested. The major issue is that the sending and receiving tasks are the same -- for a real test, the sending ought to be done on a different task from the receiving.

The following important scenarios aren't tested (there may be more too):

• the clone method on Sender/Receiver
• dropping a Sender or Receiver when multiple ones exist already, rather than just a single one.
• Trying to send to or receive from a disconnected channel
• Whether the Receiver::sender() and Sender::receiver() methods properly change the Channel's state in the case of multiple endpoints or a single endpoint.
• Actually recovering from a channel disconnection using the above methods and then successfully sending and/or receiving through the channel
• Anything with more than two tasks -- a common use case would be to have several sending tasks and several receiving tasks, so we want to test whether that works properly.

Testing is tough, but in general the goal is to be as rigorous and difficult as possible in order to stress the mechanisms we've implemented rather than test only the easiest scenarios.

[kevinaboos]

the main function cannot be parameterized with generic types, since there's no way to invoke it. Have you actually tried to run it to see what happens? T would be nothing, i.e., random junk, meaning it would sporadically fail in the oddest ways.

[kevinaboos]

The test app itself would need to choose a type for T, or a few different types across different test iterations

[amab8901]

How can I use the Sender<T> then, without introducing generic parameter T?

[kevinaboos]

you choose a type when you create the channel, just like with Rust's std channels. So, something like:

let (sender, receiver) = new_channel::<u64>(...);
let (sender, receiver) = new_channel::<String>(...);
let (sender, receiver) = new_channel::<YourCustomTypeThatImplsSend>(...);

[kevinaboos]

rather than making the Channel type public, or any of its fields or methods, we should simply add methods to Sender and Receiver that invoke the private Channel methods.

I think the only one we really need is channel_status(), so you can add a Sender::channel_status() and Receiver::channel_status() that just call the existing function within Channel.

The reason for this is to achieve proper encapsulation through limited visibility -- we don't necessarily want a caller to be able to access any and all fields/methods within Channel, because then they could potentially violate its semantics by changing things in unforeseen ways.

[kevinaboos]

you should print something or assert something in the receiver task, and vice versa for the other example.

[kevinaboos]

warning is good, but asserting or throwing an error would be even better. It is a test, after all, so failures should be loud.

[amab8901]

Thanks! The initial set of tests is decent, but there are a few more scenarios that ought to be tested. The major issue is that the sending and receiving tasks are the same -- for a real test, the sending ought to be done on a different task from the receiving.

How can I tell whether the sending and receiving tasks are the same?

[kevinaboos]

How can I tell whether the sending and receiving tasks are the same?

Just like with regular Rust, unless you manually spawned a new task, all of your code in a function or within a series of functions that call each other will all run in the same task. Here I'm suggesting that you create a test scenario that is more representative of real-world channel usage, in that the sender(s) and receiver(s) are typically on different tasks, as it doesn't make much sense for a task to send itself a message via a channel.