Task #3371
closedUdpChannel: test suite improvement
Added by Junxiao Shi almost 9 years ago. Updated over 8 years ago.
100%
Description
Improve UdpChannel
test suite with coverage for these functions and situations:
- accept packets from multiple remote endpoints, and check each face works
- after a face is closed, it's removed from the channel
Reference: commit:65caf200924b28748037750449e28bcb548dbc9c udp.t.cpp
, MultipleAccepts ManualClose IdleClose
test cases.
Updated by Spencer Lee over 8 years ago
- Status changed from New to In Progress
BOOST_AUTO_TEST_CASE_TEMPLATE(MultipleAccepts, A, EndToEndAddresses)
{
LimitedIo limitedIo;
UdpFactory factory;
// channel1 is listening
shared_ptr<UdpChannel> channel1 = factory.createChannel(A::getLocalIp(), A::getPort1());
std::vector<shared_ptr<Face>> faces1;
channel1->listen([&] (shared_ptr<Face> newFace) {
faces1.push_back(newFace);
limitedIo.afterOp();
},
[] (const std::string& reason) { BOOST_ERROR(reason); });
The reference A, as in A::getLocalIp() is used throughout the deleted reference, http://gerrit.named-data.net/#/c/2632/5/tests/daemon/face/udp.t.cpp
I'm not sure where A is located - does not seem to be in the test, I'm wondering if anyone has any insight on this.
Also, I believe UdpChannel and UdpFactory pass Endpoint and a timeout to create channels. It seems like a port number is passed as the timeout parameter. Is there a reason for this, or is this arbitrary to represent an insignificant timeout amount?
Updated by Junxiao Shi over 8 years ago
Answer to note-1:
In the given snippet, A
is a "formal type parameter name", which refers to one of the types in the collection EndToEndAddresses
.
See BOOST_AUTO_TEST_CASE_TEMPLATE
documentation.
Updated by Davide Pesavento over 8 years ago
This task is in progress but has no assignee. Who's working on it?
Updated by Spencer Lee over 8 years ago
Sorry about that -
UdpChannel and UdpFactory pass Endpoint and a timeout to create channels.
It seems like a port number is passed as the timeout parameter, from the code block above.
Is there a reason for this, or is this arbitrary to represent an insignificant timeout amount?
Updated by Davide Pesavento over 8 years ago
I suppose the above code is using this overload:
shared_ptr<UdpChannel>
createChannel(const std::string& localIp, const std::string& localPort,
const time::seconds& timeout = time::seconds(600));
Updated by Spencer Lee over 8 years ago
- Status changed from In Progress to Code review
Updated by Spencer Lee over 8 years ago
On gerrit:
- This test suite should look almost identical to the TcpChannel one, except maybe for the fixture. In fact, we could even share the implementation of most test cases via test case templates.
How can sharing of the test cases be done by a test case template? Does that mean a file to be used by similar suites should be created and templates should be defined within that file?
Updated by Davide Pesavento over 8 years ago
You use BOOST_FIXTURE_TEST_CASE_TEMPLATE
, usually together with boost::mpl::vector
.
However I don't want to complicate this task for you. If you don't know how to use test case templates, just write a regular test suite for UdpChannel, but try to keep it as similar as possible to the TcpChannel one in http://gerrit.named-data.net/#/c/2705/16; I will then unify the two suites using templates in a follow-up patch.
Updated by Spencer Lee over 8 years ago
Is it correct to say that ManualClose is equivalent to FaceClosure of TestTcpChannel, and can be replaced by a corresponding FaceClosure test?
Should there be a corresponding ConnectTimeout test in UdpChannel?
Updated by Davide Pesavento over 8 years ago
Spencer Lee wrote:
Is it correct to say that ManualClose is equivalent to FaceClosure of TestTcpChannel, and can be replaced by a corresponding FaceClosure test?
Yes. In fact we don't need to differentiate between manual and idle closure in TestUdpChannel, because those tests are already done for the transport.
Should there be a corresponding ConnectTimeout test in UdpChannel?
No. There is not concept of timeout in UdpChannel::connect
.
Updated by Junxiao Shi over 8 years ago
- Blocks Task #3514: Merge Channel test cases as template added
Updated by Junxiao Shi over 8 years ago
- Status changed from Code review to Closed