调试不稳定的测试
我们现在知道了如何通过设计来防止测试失灵。但是，如果你已经在处理一个不稳定的测试了呢？你怎么能摆脱它呢？
当我在调试的时候，把有缺陷的测试放在一个循环中，对我发现易碎性有很大帮助。例如，如果你运行一个测试50次，而且每次都能通过，那么你就可以更确定这个测试是稳定的--也许你的修复措施起了作用。如果不是，你至少可以更深入地了解这个不稳定的测试。
// Use in build Lodash to repeat the test 100 times
Cypress._.times(100, (k) => {
it(`typing hello ${k + 1} / 100`, () => {
// Write your test steps in here
})
})
在CI中，获得对这种不稳定测试的更多了解尤其艰难。为了获得帮助，看看你的测试框架是否能够获得更多关于你的构建的信息。当涉及到前端测试时，你通常可以在你的测试中利用一个console.log 。
it('should be a Vue.JS component', () => {
// Mock component by a method defined before
const wrapper = createWrapper();
// Print out the component’s html
console.log(wrapper.html());
expect(wrapper.isVueInstance()).toBe(true);
})
这个例子取自一个Jest单元测试，我在其中使用了一个console.log ，以获得被测试组件的HTML输出。如果你在Cypress的测试运行器中使用这种记录的可能性，你甚至可以在你选择的开发者工具中检查输出。此外，当涉及到CI中的Cypress时，你可以通过使用一个插件在你的CI的日志中检查这个输出。
始终关注你的测试框架的功能，以获得对日志的支持。在UI测试中，大多数框架都提供截图功能--至少在失败时，会自动进行截图。有些框架甚至提供视频记录，这对深入了解测试中发生的情况有很大帮助。
对抗虚弱的噩梦
重要的是，要不断地寻找故障测试，无论是从一开始就防止它们发生，还是在它们发生后立即进行调试和修复。我们需要认真对待它们，因为它们可以暗示你的应用程序中的问题。
识别红旗
当然，最好是在第一时间内防止故障测试的发生。快速回顾一下，这里有一些红旗。
·测试是大型的，包含很多逻辑。
·测试涵盖了大量的代码（例如，在UI测试中）。
·测试使用了固定的等待时间。
·测试依赖于以前的测试。
·该测试断言的数据不是100%可预测的，如使用ID、时间或演示数据，特别是随机生成的数据。
如果你牢记本文的指针和策略，你就可以在测试发生之前防止闪失。如果它们真的来了，你将知道如何调试和修复它们。
这些步骤确实帮助我恢复了对我们测试套件的信心。目前，我们的测试套件似乎很稳定。未来可能会有问题 - 没有什么是100%完美的。这些知识和这些策略将帮助我处理它们。因此，我将对自己对抗那些片状测试噩梦的能力越来越有信心。
我希望我至少能够减轻你的一些痛苦和对片状物的担忧!
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
