Big Buck Bunny如何帮助追踪bug

本文来自Demuxed2021，演讲主讲人是来自LinkedIn媒体团队的前台工程师Evan Farina。主题是如何在测试中使用真实媒体回放来捕捉准备进入生产阶段的bug，并在第一时间防止它们进入生产阶段。

媒体事件是异步的、不可预测的，那么为什么要用行为同步并且可预测的mock来测试媒体功能呢？这个演讲将探讨一个围绕在测试中播放真实媒体的媒体测试策略，并讨论通过这些测试如何发现代码中的竞争条件和集成失败。

在过去，Evan Farina的团队在所有的媒体测试中都使用了mock。因为mock具有高度的确定性，而且设置起来非常简单。测试首先需要注册一个mock，然后将接受所有对媒体或媒体组件的调用，并将它们重新路由到mock。虽然这对于很多用例来说是可行的，但是mock并不能接近真实媒体的复杂性和不可预测性。

使用真实媒体进行测试有多个好处。首先是你不必维护一个mock。现在mock在某些情况下是简单，易于维护的，但在媒体的情况下，特别是如果你使用第三方播放器库，mock会变得复杂，并会消耗大量时间维护。但最重要的是，我们可以在你的播放器进入生产之前，就发现它们的竞赛条件和集成失败。而这将使你的bug成本大幅下降。

第二，他们发现了一个低效的媒体加载流。我们的代码走的可能并不是认为的生产路径，而是一个效率较低的路径。而Evan Farina之所以发现这一点，是因为与该代码路径相关联的跟踪事件在不该发生的时候发生了。最后，也是最让主讲人感兴趣的是，经过测试发现，当运行媒体的机器CPU使用率过高时，Chrome（也可能是其他浏览器）会对媒体事件进行节流。所以当机器的资源很少时，它会开始节流媒体事件。而这不仅会影响测试，也会影响面向用户的功能和跟踪。

第三，当你第一次过渡到在测试中使用真实媒体播放时，Evan Farina建议记录所有媒体事件。原因是，使用真实媒体很可能会发现你不知道你的应用代码中存在的竞赛条件，而这将导致测试失败。但问题是，你会在一个黑匣子里工作，这意味着你无法理解媒体发生了什么，以及到底为什么会导致你的测试失败。所以Evan Farina解决这个问题的方法是，在几个月的时间里，把所有的媒体事件都注销，直到测试完全稳定为止。最后，确保你正在监控你的测试资源。正如前面提到的，如果测试机的CPU运行过高，媒体事件就会被节流，这将导致你的测试失败。在主讲人给出的案例中，发生这种情况是因为并行运行了太多的测试。因此，限制并行运行的测试数量确实有很大的不同。

附上演讲视频：