Task #3373
closedWebSocketChannel: test suite improvement
Added by Junxiao Shi almost 9 years ago. Updated over 8 years ago.
100%
Description
Improve WebSocketChannel
test suite with coverage for these functions and situations:
- overall normal usage scenario
setPingInterval setPongTimeout
and their effects
Updated by Junxiao Shi almost 9 years ago
- Related to Task #3374: WebSocketTransport: test suite improvement added
Updated by Junxiao Shi over 8 years ago
- Assignee set to Weiwei Liu
@Weiwei: consult @Wentao Shang if you have question on websocketpp library.
Updated by Weiwei Liu over 8 years ago
I have two questions about this task.
- I'm not sure what exactly should be included in the test case for "overall normal usage scenario", or is there any similar test suite that I can refer to?
- How am I supposed to check the effects of setPingInterval and setPongTimeOut?
Could someone please help to answer?
Thanks a lot!
Updated by Weiwei Liu over 8 years ago
- % Done changed from 0 to 70
Updated by Junxiao Shi over 8 years ago
what exactly should be included in the test case for "overall normal usage scenario"
See TODOs in the placeholder test suite.
Unlike other channel test suites, WebSocketChannel
test suite should check the transport is able to send and receive packets, because transports are relying on the channel for communication.
How am I supposed to check the effects of setPingInterval and setPongTimeOut?
If websocketpp provides a getter for this operation, inspect the value via the getter.
Otherwise, test its behavior.
Ping interval can be observed by measuring the interval between received PINGs on a WebSocket client.
Pong timeout can be observed by measuring the duration between a WebSocket client receiving but not responding to a PING and the channel failing the transport.
Updated by Weiwei Liu over 8 years ago
- Status changed from In Progress to Code review
Updated by Davide Pesavento over 8 years ago
Patch set #3 sends and receives Interest packets between the face created by the channel and the "remote" mock client, and has some logic to decode received websocket messages and so on. Do we really care about this? I mean, does it have to be a valid Interest packet that goes through and gets decoded and compared on the other side? Can't we just send random bytes like in the transport tests? Or, can we send interests from the face (since it has a sendInterest()
interface) but then just check byte-by-byte on the other side, without decoding?
Updated by Junxiao Shi over 8 years ago
Answer to note-8:
No, Transport and Channel test suites do not need to use network layer packet types.
However, it's also bad to use "random bytes" because testing a random pattern is more difficult than using a known pattern.
It's sufficient to send a valid TLV block with arbitrary type and payload, and verify that the received block is the same.
This TLV block is not required to represent a network layer packet.
Transport and Channel test suites should not rely on Face
or LinkService
when possible.
Updated by Junxiao Shi over 8 years ago
- Blocks Task #3514: Merge Channel test cases as template added
Updated by Davide Pesavento over 8 years ago
Junxiao Shi wrote:
No, Transport and Channel test suites do not need to use network layer packet types.
However, it's also bad to use "random bytes" because testing a random pattern is more difficult than using a known pattern.It's sufficient to send a valid TLV block with arbitrary type and payload, and verify that the received block is the same.
This TLV block is not required to represent a network layer packet.
Yes that's what I meant, sorry for the imprecision. An arbitrary payload, as in "anything but fixed and statically known", not "random" as in "randomly generated at runtime". Thanks for the correction.
Updated by Weiwei Liu over 8 years ago
For test cases SetPongTimeOut and SetPingInterval, it seems not possible to use UnitTestTimeFixture to make them execute faster, since websocket need to wait for something in real time.
Updated by Junxiao Shi over 8 years ago
I agree with note-12. It needs a real TCP socket connection that depends on the kernel.
Updated by Junxiao Shi over 8 years ago
- Status changed from Code review to Closed
- % Done changed from 70 to 100