WebRTC/Test Plan/Peer Connection
From MozillaWiki
Contents
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.
