WebRTC/Test Plan/Peer Connection: Difference between revisions
Jump to navigation
Jump to search
(→Smoke) |
|||
| Line 15: | Line 15: | ||
=== Smoke === | === Smoke === | ||
* Typical handshake 1:1 between two peers should result in | * Typical handshake 1:1 between two peers with gUM streams added at the start of the handshake should result in the following: | ||
** Each peer has a single local and remote stream set correctly | |||
** onaddstream callback fires with the correct stream after the remote session description is set | |||
=== Basic Functional === | === Basic Functional === | ||
Revision as of 21:23, 6 April 2013
DOM Analysis Test Cases
Flows & Edge Cases 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
- Media flow and changes to it with streams across each peer
- Media constraints applied during offer, answer, or adding of streams
Smoke
- Typical handshake 1:1 between two peers with gUM streams added at the start of the handshake should result in the following:
- Each peer has a single local and remote stream set correctly
- onaddstream callback fires with the correct stream after the remote session description is set
Basic Functional
- Two typical handshakes between two peers
Exploratory
Definitions
Typical Handshake
- PC 1 calls createOffer
- PC 1 calls setLocalDescription with that offer from step #1
- PC 2 calls setRemoteDescription with that offer from step #1
- PC 2 calls createAnswer
- PC 2 calls setLocalDescription with that answer from step #4
- PC 1 calls setRemoteDescription with that answer from step #4