Early in the development of a streaming service, using a ‘mock’ player is a good way to be able to quickly test your code, in fact, it’s common to create mock API endpoints. The trouble with mocks is that they are too perfect as they lack the complex behaviour of a real player playing real media.
Evan Farina from LinkedIn explains what they’ve found while developing the LinkedIn video player. Communication from media players comes in the form of tracking events that indicate status such as ‘playing’ or ‘duration’. So when a player initiates playing of a video stream, a tracking event would come back to indicate success or otherwise. When using a mock, if your program works, so will the tracking event. In the real world, these values might be empty, have invalid data in or be functioning just as expected.
Once you’re in production, swapping your mock for real media has benefits. Evan explains that no longer needing to create/maintain a mock is a time saver. After all, it is code and you need to make sure it’s working and keeping up with production changes. But the main benefit is catching player integration issues and race conditions before releasing to production. Evan’s team found errors in tracking events, inefficiencies in the way media was being loaded and a dependency on free CPU which was previously unknown. All of this was possible before deploying into production.
How can you switch from mocks to real media? One goal is to ensure your tests aren’t reliant on any timing meaning your testing and the player need to be fully asynchronous. To do this, Evan’s created ‘helpers’ which control media playback (play, pause, seek etc) and also wait for a result with a timeout in case they never receive the resultant tracking event.
Evan finishes with some tips for scaling from his team. Firstly, there’s no point making your test take longer than necessary so keep media short. Second: store media locally to avoid network traffic not directly related to the test. Log all events since, at some point, these will be critical to understanding a problem. Lastly, he says to make sure you monitor your test servers since it’s important to make sure they’re not struggling to cope with the load which could affect the results of some of your tests.
Watch now!
Speakers
 |
Evan Farina Software Engineer, |
