在涉及行为驱动和单元测试时，什么构成了敏捷性？
今天上午，我在PHPSPec上做了一个演讲，官方网站描述如下：
一个php工具集，用于按规范驱动紧急设计。
在形容词上下文中，“紧急”一词的定义如下：
形成的过程
另一方面，据说PHPUnit专注于快速代码提交，并断言代码的其他部分没有出现代码倒退。
话虽如此，从演示中得出的论点是，PHPSpec仍然是我所做的单元测试框架，我对此没有异议，但我认为我的更多关注的是这个工具真正关注的是设计。
这两种工具之间的区别在这个关于Laracast的文章中得到了简洁的解释。
现在来了敏捷方法论，解释了这里和这里。关于敏捷方法的后一篇文章重点提到了为什么这种方法更好(节选见下文)。
当您将敏捷原则集合起来，在敏捷框架中实现它们，利用协作工具，并采用敏捷开发实践时，您通常会得到更高质量的应用程序、更快开发的应用程序和更好的技术实践(也就是卫生习惯)。
这个观点是，PHPSpec没有提供PHPUnit没有提供的任何东西。然而，如果我们深入了解工程学科及其内容，我们几乎可以看到提到工具(见下文节选)：
它包含的概念，原则，理论，技术和工具，可用于开发高质量的专业软件。
从持续集成工具的角度来看这一切，在这种情况下，包括PHPSpec、PHPUnit、Behat、context等等，以实现不同的测试策略。在工程环境中，所有这些工具都可以发挥作用。但是，在敏捷环境中，其中一种似乎不能使用另一种，特别是PHPSPec。我认为缺乏的是一个真实的环境，一个人可以真正驱动测试驱动和行为驱动的设计，特别是使用这两个工具。
我可能看错了敏捷环境中的事物，再加上交付高质量代码的软件工程策略等等。我并不自称是无所不知的先生，我的目标是在我的职业中努力变得更好和更有见识，从而提高我的技能。
有人能帮我理解一下在PHP环境下与软件工程相结合的敏捷方法，以及如何利用现成的测试工具和策略来实现软件产品开发过程吗？提前谢谢你。
回答 1
Software Engineering用户
发布于 2018-06-06 23:08:32
行为驱动和单元测试是支持敏捷实践驱动的整个开发过程的可行性/成功的一些技术方面。
敏捷性来自于更少的迭代/时间来实现有效满足实际(实际增值)用户需求的产品[1]，因为这些原因：
- 您提到的敏捷原则/框架本质上推动了用文档替代瀑布范式，该范式仅在第一个分析阶段寻找定义所有需求的文档，方法是向用户提供一个工作应用程序(不完整)，快速获得反馈，并计划下一个简短的迭代/冲刺，用户通过一个实际工作的app.进行反馈--这是因为在大多数情况下，用户发现他们实际和最优先的需求使用一个工作应用程序并与其交互(即使不完整)，这是一个比只使用文档的长分析阶段更好的方法。[2] 这样的过程更敏捷，因为它是由具有不断用户反馈的小迭代/冲刺驱动的，从而更快地实现了满足实际需求的产品，并提供了更多的附加值。[3.]
- 为了支持这种未来变化的不确定性，以及在没有风险的快速小步骤(迭代/冲刺)中实现这些变化的需要，源代码需要有一个非常好的架构/设计，灵活且随时可以更改，而不是错误或脆弱。[4.]这里是行为驱动，TDD，单元测试，.(XP实践)作为帮助生成更健壮的源代码的技术实践(可以在安全的way.需求中进行更改)编写为源代码示例(单元/集成/验收/e2e测试)，而不是通常会过时的word文档。CI (连续集成)确保编写为源代码的这些需求在每个开发人员的签入中得到验证。[5] 3 TDD步骤(TDD的循环:红绿重构)确保当前迭代所需的源代码不超过已知的为用户提供价值的源代码，避免处理过度设计的代码。还使开发人员同时关注不同的开发方面:将需求定义为自动化测试，在实现当前测试的源代码时创建算法，以及在重构步骤上设计和架构。[6] 在不同的时间将软件开发的这三个方面分开，减少了当开发人员在实现算法时意识到没有考虑到的场景时所产生的bug风险，并且他们必须同时进行这三个方面的开发。[7] 单元测试确保源代码必须遵循SR (单责任)和DI (依赖反转)原则(在所有五项坚实原则中)，其他良好实践和设计模式应用于重构阶段，但是由于源代码符合SR、DI，并且需求是用CI自动测试的，团队可以更有信心地重构，而不是担心意外的副作用。
- 所有这些实践，如果它们都得到了很好的实现，就会以高质量的代码、健壮的、随时可以更改的代码结束。允许团队对用户的反馈进行更快的迭代，也可以对甚至用户都无法控制或预测的意外市场变化进行迭代。
- 这是来自敏捷，与瀑布范式相比(当用于需要大量创新或对未来需求不确定的场景时)，这种策略通常是过度设计，试图预测可能的进化，这可能会使软件在真正的市场/用户需求的变化到来时变得过于复杂和难以进化，特别是无法很好地覆盖自动化测试，更改会产生意外的副作用，项目会被许多bug和长时间的QA稳定阶段所延迟，这会产生对更改的恐惧，有时会以不优化的补丁/解决方案而告终，而不是产生最糟糕的脆弱/脆弱源代码的必要的复制因素，更难维护和进化。[8]
https://softwareengineering.stackexchange.com/questions/371560
复制相似问题
腾讯云开发者
