WebRTC/Test Plan/Peer Connection

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
• 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:
  • A signalingState of stable
  • An iceConnectionState of new
  • An iceGatheringState of new
• Typical handshake 1:1 between two peers with 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

• Two typical handshakes between two peers

Definitions

Typical Handshake

1. Local PC calls createOffer
2. Local PC calls setLocalDescription with that offer from step #1
3. Remote PC calls setRemoteDescription with that offer from step #1
4. Remote PC calls createAnswer
5. Remote PC calls setLocalDescription with that answer from step #4
6. 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.