WebRTC/Test Plan/Peer Connection: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (19 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== DOM Analysis Test Cases == | == DOM Analysis Test Cases == | ||
=== Flows | === Flows to Consider === | ||
* Happy path flows for typical peer connection handshakes | |||
* Multiple peers making peer connection handshakes | |||
* Adding of ice candidates generated during handshake | |||
* Closing of connections | |||
* State changes throughout peer connection handshake and it's effects on attributes and event handlers | |||
* Negative flow - add multiple streams of the same type | |||
* Negative flow - Out of order execution of the handshake between two peers | |||
* Negative flow - bad values into each supported API function | |||
* Media flow and changes to it with streams across each peer - pausing of media, releasing the stream through stop(), etc | |||
* Media constraints applied during offer, answer, or adding of streams | |||
=== Smoke === | === Smoke === | ||
* Creation of a peer connection with a valid STUN server should result in the valid post peer connection creation state | |||
* Typical handshake 1:1 between two peers with different gUM streams added at the start of the handshake should result: | |||
** Each peer has a single local and remote stream set correctly | |||
** onaddstream callback fires with the correct stream that generates media flow after the remote session description is set | |||
=== Basic Functional === | === Basic Functional === | ||
* Creation of a peer connection with a valid STUN server that requires credentials and has valid credentials provided should result in a valid post peer connection creation state | |||
* Creation of a peer connection with a valid STUN server that requires credentials and has invalid credentials provided should result in an exception firing | |||
* Two typical handshakes between two peers with different gUM streams added at the start of the handshakes should result: | |||
* | |||
=== Exploratory === | === Exploratory === | ||
* | |||
=== Definitions === | |||
==== Post Peer Connection Creation State ==== | |||
* A signalingState of stable | |||
* An iceConnectionState of new | |||
* An iceGatheringState of new | |||
==== Typical Handshake ==== | |||
# Local PC calls createOffer | |||
# Local PC calls setLocalDescription with that offer from step #1 | |||
# Remote PC calls setRemoteDescription with that offer from step #1 | |||
# Remote PC calls createAnswer | |||
# Remote PC calls setLocalDescription with that answer from step #4 | |||
# Local PC calls setRemoteDescription with that answer from step #4 | |||
==== Media Flow Validation ==== | |||
Media flow is validated based off of streams by checking attributes of a stream attached to a media element playing by analyzing if playing-based events fire (e.g. timeUpdate, canplaythrough), time is moving forward on the stream and media element, and that state changes on the media element built off the stream are correct. | |||
== Localhost Real Stream Test Cases == | == Localhost Real Stream Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 21: | Line 65: | ||
== Remote Real Stream Test Cases == | == Remote Real Stream Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | |||
=== Basic Functional === | |||
=== Exploratory === | |||
== Interoperability Test Cases == | |||
=== Flows to Consider === | |||
=== Smoke === | === Smoke === | ||
Latest revision as of 21:55, 6 April 2013
DOM Analysis Test Cases
Flows to Consider
- Happy path flows for typical peer connection handshakes
- Multiple peers making peer connection handshakes
- Adding of ice candidates generated during handshake
- Closing of connections
- State changes throughout peer connection handshake and it's effects on attributes and event handlers
- Negative flow - add multiple streams of the same type
- Negative flow - Out of order execution of the handshake between two peers
- Negative flow - bad values into each supported API function
- Media flow and changes to it with streams across each peer - pausing of media, releasing the stream through stop(), etc
- Media constraints applied during offer, answer, or adding of streams
Smoke
- Creation of a peer connection with a valid STUN server should result in the valid post peer connection creation state
- Typical handshake 1:1 between two peers with different gUM streams added at the start of the handshake should result:
- Each peer has a single local and remote stream set correctly
- onaddstream callback fires with the correct stream that generates media flow after the remote session description is set
Basic Functional
- Creation of a peer connection with a valid STUN server that requires credentials and has valid credentials provided should result in a valid post peer connection creation state
- Creation of a peer connection with a valid STUN server that requires credentials and has invalid credentials provided should result in an exception firing
- Two typical handshakes between two peers with different gUM streams added at the start of the handshakes should result:
Exploratory
Definitions
Post Peer Connection Creation State
- A signalingState of stable
- An iceConnectionState of new
- An iceGatheringState of new
Typical Handshake
- Local PC calls createOffer
- Local PC calls setLocalDescription with that offer from step #1
- Remote PC calls setRemoteDescription with that offer from step #1
- Remote PC calls createAnswer
- Remote PC calls setLocalDescription with that answer from step #4
- Local PC calls setRemoteDescription with that answer from step #4
Media Flow Validation
Media flow is validated based off of streams by checking attributes of a stream attached to a media element playing by analyzing if playing-based events fire (e.g. timeUpdate, canplaythrough), time is moving forward on the stream and media element, and that state changes on the media element built off the stream are correct.