调试不稳定的测试
我们现在知道了如何通过设计来防止测试失灵。但是,如果你已经在处理一个不稳定的测试了呢?你怎么能摆脱它呢?
当我在调试的时候,把有缺陷的测试放在一个循环中,对我发现易碎性有很大帮助。例如,如果你运行一个测试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),我们将立即处理