WebRTC/Test Plan/Peer Connection: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (7 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 | * Happy path flows for typical peer connection handshakes | ||
| Line 10: | Line 10: | ||
* Negative flow - add multiple streams of the same type | * Negative flow - add multiple streams of the same type | ||
* Negative flow - Out of order execution of the handshake between two peers | * Negative flow - Out of order execution of the handshake between two peers | ||
* Media flow and changes to it with streams across each peer | * 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 | * Media constraints applied during offer, answer, or adding of streams | ||
=== Smoke === | === Smoke === | ||
* Typical handshake 1:1 between two peers with gUM streams added at the start of the handshake should result | * 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 | ** 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 | ** onaddstream callback fires with the correct stream that generates media flow after the remote session description is set | ||
| Line 21: | Line 23: | ||
=== Basic Functional === | === Basic Functional === | ||
* Two typical handshakes between two peers | * 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 === | ||
| Line 29: | Line 33: | ||
=== Definitions === | === Definitions === | ||
==== Post Peer Connection Creation State ==== | |||
* A signalingState of stable | |||
* An iceConnectionState of new | |||
* An iceGatheringState of new | |||
==== Typical Handshake ==== | ==== Typical Handshake ==== | ||
| Line 39: | Line 49: | ||
# Local PC calls setRemoteDescription with that answer from step #4 | # Local PC calls setRemoteDescription with that answer from step #4 | ||
==== Media Flow ==== | ==== 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. | 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. | ||
| Line 45: | Line 55: | ||
== Localhost Real Stream Test Cases == | == Localhost Real Stream Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 55: | Line 65: | ||
== Remote Real Stream Test Cases == | == Remote Real Stream Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 65: | Line 75: | ||
== Interoperability Test Cases == | == Interoperability Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 72: | Line 82: | ||
=== Exploratory === | === Exploratory === | ||
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.