Confirmed users
2,959
edits
WebRTC/Test Plan/Peer Connection: Difference between revisions
no edit summary
No edit summary |
|||
| (11 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 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 | |||
** onaddstream callback fires with the correct stream that generates media flow after the remote session description is set | |||
=== 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 27: | 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 ==== | ||
# PC | # Local PC calls createOffer | ||
# PC | # Local PC calls setLocalDescription with that offer from step #1 | ||
# PC | # Remote PC calls setRemoteDescription with that offer from step #1 | ||
# PC | # Remote PC calls createAnswer | ||
# PC | # Remote PC calls setLocalDescription with that answer from step #4 | ||
# PC | # 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 49: | Line 65: | ||
== Remote Real Stream Test Cases == | == Remote Real Stream Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 59: | Line 75: | ||
== Interoperability Test Cases == | == Interoperability Test Cases == | ||
=== Flows | === Flows to Consider === | ||
=== Smoke === | === Smoke === | ||
| Line 66: | Line 82: | ||
=== Exploratory === | === Exploratory === | ||