3
我可以使用哪些论点将BDD概念“出售”给不愿意采用它的团队？
我有点支持“行为驱动开发”方法论（又名BDD）。我已经使用BDD已有两年了，并且在开发DotNet应用程序时采用StoryQ作为我的首选框架。即使我已经进行了多年的单元测试，并且以前已经转向测试优先的方法，但我发现使用BDD框架会带来更多的价值，因为我的测试抓住了相对而言需求的意图。在我的代码中清除英语，并且因为我的测试可以执行多个断言而无需在测试进行到一半时结束测试-这意味着我可以一目了然地查看哪些特定断言通过/失败，而无需进行调试即可证明。 对于我来说，这确实是冰山一角，因为我还注意到，我能够以更有针对性的方式调试测试和实现代码，从而提高了我的生产力，并且我可以如果由于输出进入构建日志而导致问题一直困扰到集成构建，则可以轻松确定发生故障的位置。此外，StoryQ api具有很好的流利语法，易于学习，并且可以以多种方式应用，不需要外部依赖就可以使用它。 因此，有了所有这些好处，您会认为很容易将概念引入团队其他成员。不幸的是，其他团队成员甚至都不愿看StoryStorQ来对其进行正确评估（更不用说应用BDD的想法了），并说服彼此尝试从我们自己的核心测试框架中删除许多StoryQ元素，甚至尽管他们最初支持使用StoryQ，但是即使他们希望删除的代码也不会影响我们测试系统的任何其他部分。这样做将最终导致整体上显着增加我的工作量，并且确实与实际情况背道而驰，因为我通过实践经验深信，这是在特定的工作环境中以“测试优先”的方式工作的更好方法，只会导致更大的工作量。鉴于以下情况，我们的软件质量得到了改善 我们发现更容易坚持使用BDD进行测试。为了进一步澄清，我们大多数的单元测试往往都很脆弱且难以维护，多年来由于应用程序测试不佳而导致的结果是，由于不愿坚持测试驱动的流程，开发人员退回到了旧习惯，在项目结束时进行所有测试（这些人声称自己是敏捷的！）。 因此，问题实际上归结为以下几点： 我可以使用哪些论点来真正说明这个团队使用StoryQ或至少采用BDD方法会更好？ 您能否指出我能用来支持我的论点以采用BDD作为我们的标准选择方法的任何轶事证据？ 您能想到什么相反的论点，这可能表明我希望鼓励团队采用BDD的想法可能是错误的？是的，只要论据是合理的，我很高兴被证明是错误的。 注意：我并不是在主张我们全面重写测试，而只是为了以后的所有测试工作而以不同的方式开始工作，最好以与客户互动的方式开始。 对于希望进一步了解BDD的人来说，以下链接可能会有用： http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/简介 对于那些对更多细节感兴趣的人，我们是一个由4人组成的小型团队，致力于大约5个大型项目。BDD的“试验”最初进行了大约2个月，随后又进行了大约4个月。团队接受了我应该继续以这种方式工作并进行自己的尝试。自试验结束以来，我一直从事BDD工作约两年，而其他人则非常擅长回避问题。我不是在问题上施加“对抗”，而是在寻找一种方法来温和地说服团队摆脱集体的落后，并抽出时间来做好自己的工作。