本节书摘来自异步社区《Cucumber：行为驱动开发指南》一书中的第6章，第6.5节，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章节内容可以访问云栖社区“异步社区”公众号查看
6.5 我们学到了什么
Cucumber特性对公司来说是一笔宝贵的财富。我们曾见过有团队将他们系统中大块大块的部分推倒重写，知道自己有一组准确的、可执行的规范来确保新的方案会运行得跟原来一样好，他们自不必担心什么。对这些团队来说，特性比产品代码本身更有价值。如果你打算在编写Cucumber特性上面做些投入，那就要照管好这些特性，让他们为整个团队带来尽可能多的益处，从而保护好这笔投入。不要迁就于缓慢的特性、间歇失败的特性或者团队中只有一部分人阅读的特性：问题一旦出现立该将其消除，让每个问题成为一个理由，基于这些理由把测试做得比以前更好。
Cucumber看上去似乎只是一种测试工具，但本质上它是一种协作工具。如果你真正努力去编写特性，使它们可作为文档提供给团队中的非技术利益相关人，你会发现自己不得不与利益相关人讨论一些原本你不会花时间讨论的细节。这些讨论揭示了他们对问题的深刻见解，这些见解将帮助你构建一套更好的方案。这才是Cucumber的真正奥秘：测试和文档都只是令人愉快的副作用而已，真正的价值在于交谈过程中对于知识的发掘。
尝试一下
下面是一些你可以自行尝试的练习。
在团队中实施缺陷预防
想出使团队生产线速度变慢的三件事情。每件事情的根源是什么？你可以做些什么来使它们向着好的方向变化？
关于偶然细节的练习
下面的场景是以丑陋的命令式风格编写的，穿插着各种偶然细节。
Scenario: Create an invoice
Given I am a signed in user with role: admin
And a client "Test Client" exists with name: "Test Client"
And a project "Test Project" exists with:
| name | "Test Project" |
| client | client "Test Client" |
And an issue "Test Issue" exists with:
| project | project "Test Project" |
| name | "Test Issue" |
And a work_unit "Test Work Unit" exists with:
| issue | issue "Test Issue" |
| completed_on | "2011-08-24" |
| hours | "7.5" |
And I am on the admin invoices page
Then I should see "Test Client"
And I follow "Test Client"
And I fill in "invoice_id" with "abc"
And I press "Submit"
Then I am on the admin invoices page
And I should not see "Test Client"
首先弄清楚来龙去脉：你认为这个系统是做什么的？场景的用途是什么？它在测试怎样的行为？注意那些像蔓生杂草一般的偶然细节是如何妨碍你理清测试的实际目标的。
理解了场景的实质目标之后，基于自己的词汇把它重写一遍。需要的步骤应该可以少很多，但你可能会考虑使用多个场景。
用更加声明式的风格重写场景之后，你能找到原先场景中遗漏的一个关键的Then步骤吗？
