第6章 Cucumber常见问题及解决之道
如果团队是第一次用Cucumber，用不了多久你就会注意到自己写的代码bug比以前少了。你发现自己可以勇敢地重构那些以前碰都不敢碰的代码。看到自己的第一个场景通过时的那种喜悦，鼓舞着你不断添加一项又一项特性。
然而，一段时间后，事情开始变味了。突然间你发现测试运行的时间实在太长；或者你开始注意到有几个场景会随机地失败，而且通常是在紧张的工期已经临近的时候；也可能不懂技术的利益相关人对这种开发过程兴趣渐失，只剩下开发人员还在阅读那些特性。人们甚至开始问这样的问题：
Cucumber是不是妨碍了我们的工作？
好消息是，这些问题都是有办法解决的。我们在教练和顾问咨询工作中曾见过各种各样的团队在学习使用Cucumber时遭遇各式各样的问题。在本章中，我们将描述曾经见过的最常见的问题。我们会帮你理解这些问题的根源，给出应对它们的建议，或者，更理想一点儿，从一开始就避免它们。本章没有太多代码，但有大量有用的建议。
我们首先从问题入手，描述你的团队可能经历的4种不同症状，然后我们会深入分析这些问题背后的原因，最后考察解决的方法。到本章结束时，你应该会对如何帮助团队从长远角度成功运用Cucumber持有更大的信心。
6.1 感受痛苦
我们从Cucumber出现问题时团队可能感受到的痛苦中找出了主要的4种类型。看看其中有没有你熟悉的。
下面我们仔细看看上表中所示的每一种症状。
6.1.1 闪烁的场景
一个场景，同样的源代码同样的环境，昨天还能通过，今天却失败了，我们将这种情形称为闪烁的场景。下面是我们对闪烁的场景的定义。
闪烁的场景
闪烁的场景偶尔失败，随机失败。同一个场景在相同环境的同一套代码库上运行，大多数时候能通过，有时却失败。这些似乎难以控制的失败使团队对测试、代码和自身都失去了信心。
闪烁的场景最让人讨厌的一点是：一旦你尝试重现它以便修复时，它反而不再失败了。修复闪烁的场景是最困难的任务之一，也是最重要的任务之一。一组自动测试套件要想有用，团队必须完全信任它。如果连单个测试都在破坏这种信任，那就会腐蚀团队中各个成员对整个测试套件的信任感。
为修复闪烁的场景，你必须研究代码，努力搞清楚它为什么会发生。这是一种科学过程：对失败原因做出一种假设，设计一个实验来证实或证伪这一假设，然后执行实验看自己是否正确。你可能需要多次重复这一循环才能找到问题的答案，如果闪烁的场景总是间歇地失败，执行一个实验可能需要好几天。如果想法儿用光了，宁可考虑将整个测试删除，也不要由着它自行选择失败的时间再回来折腾你。
6.1.2 脆弱的特性
你感觉测试套件让你几乎无法写代码，因为总会有明显不相关的测试亳无理由地失败，我们将这种情况称为脆弱的特性。下面是我们对脆弱的特性的定义。
脆弱的特性
脆弱的特性极易被破坏。特性脆弱时，在测试套件或主代码库的某个部分做些必要的修改会破坏明显不相关的场景。
遇到脆弱的场景时，通常你是在做其他事情的时候。你被不期而至的失败中断了，只好赶紧花时间去修复这意料之外的测试失败。运气不好的日子里，这种情况会多次发生，害你深陷其中而迟迟不能自拔。脆弱的特性具有自我实现性：当开发人员察觉到自己的测试脆弱不堪时，他们常常就更没有勇气重构或清理测试代码，相反他们会尽量快进快出，以求早一点远离是非之地，于是测试和产品代码便越来越难维护了。
6.1.3 缓慢的特性
每次往测试套件中添加一个新的场景，便在测试运行的总体时间中增加了几秒。对一个用户不断要求新特性的成功应用来说，测试运行的时间只会变得越来越长。长时间的测试正慢慢向你靠近：一开始5分钟已经够让人难耐了；之后，15分钟，虽然糟糕，但你已经习惯了在它运行时去喝杯咖啡；用不了多久，等你喝完咖啡回来它依然没有结束，15分钟变成了25分钟；然后在不知不觉中，你的特性已经需要运行一小时甚至更长时间了。
新的场景一旦通过，继续运行它的主要原因就是获得反馈：如果你不小心破坏了它所检查的功能，你希望场景可以给出警告。可随着测试运行的时间越来越长，这种反馈的价值也就减少了。项目构建太慢时，开发人员在提交代码前便不再运行全部测试，转而依靠持续集成服务器来提供反馈。如果多名开发人员同时这么做，他们所做的全部修改能集成到一起的概率也就不敢指望了，失败的构建于是就成了家常便饭。
测试运行时间长还意味着人们不敢动手对Cucumber测试做重构或其他常规维护。如果某个步骤定义在340个场景中使用，重构其代码是骇人的，因为你需要运行全部340个场景才能确切地知道自己的改动有没有破坏了什么。
6.1.4 厌倦的利益相关人
有的团队尝试使用Cucumber，最终却只把它当做了测试脚本的自动化工具，这样的团队中，最常听到的一句抱怨就是“利益相关人不愿阅读我们写的特性”。但也有许多团队证实Cucumber确实能带来改观，有助于开发团队更加有效地同业务利益相关人协作。这两种不同的体验差别源自哪里呢？
答案的一部分在于要从一开始就同业务利益相关人建立正确的协作关系。如果他们觉得自己太忙，没时间帮你准确理解他们想要的东西，那么你面对的是一个更深层的团队问题，Cucumber爱莫能助。但另一方面，许多团队开始时倒是有热心主动的利益相关人，可团队却浪费了Cucumber带来的建立这种协作关系的机会。如果测试人员或开发人员独自编写特性，他们就难免使用技术术语，这样利益相关人在阅读的时候会觉得自己被边缘化了。这会变成恶性循环：利益相关人本来可以帮助你使用对他们有意义的语言编写特性，但随着兴趣渐失，他们花在这上面的时间会越来越少。不知不觉中，特性就沦为纯粹的测试工具了。
团队中一旦发现这类症状，就需要知道如何处理。这正是调查工作背后存在的问题并考虑应对措施的时机。