Project

General

Profile

Actions

Task #3373

closed

WebSocketChannel: test suite improvement

Added by Junxiao Shi almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

Improve WebSocketChannel test suite with coverage for these functions and situations:

  • overall normal usage scenario
  • setPingInterval setPongTimeout and their effects

Related issues 2 (0 open2 closed)

Related to NFD - Task #3374: WebSocketTransport: test suite improvementClosedWeiwei Liu

Actions
Blocks NFD - Task #3514: Merge Channel test cases as templateClosedDavide Pesavento

Actions
Actions #1

Updated by Junxiao Shi almost 9 years ago

  • Related to Task #3374: WebSocketTransport: test suite improvement added
Actions #2

Updated by Junxiao Shi over 8 years ago

  • Assignee set to Weiwei Liu

@Weiwei: consult @Wentao Shang if you have question on websocketpp library.

Actions #3

Updated by Weiwei Liu over 8 years ago

  • Status changed from New to In Progress
Actions #4

Updated by Weiwei Liu over 8 years ago

I have two questions about this task.

  1. 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?
  2. How am I supposed to check the effects of setPingInterval and setPongTimeOut?

Could someone please help to answer?

Thanks a lot!

Actions #5

Updated by Weiwei Liu over 8 years ago

  • % Done changed from 0 to 70
Actions #6

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.

Actions #7

Updated by Weiwei Liu over 8 years ago

  • Status changed from In Progress to Code review
Actions #8

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?

Actions #9

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.

Actions #10

Updated by Junxiao Shi over 8 years ago

  • Blocks Task #3514: Merge Channel test cases as template added
Actions #11

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.

Actions #12

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.

Actions #13

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.

Actions #14

Updated by Junxiao Shi over 8 years ago

  • Status changed from Code review to Closed
  • % Done changed from 70 to 100
Actions

Also available in: Atom PDF