TDD、BDD和DDD – 绝佳的互补
TDD、BDD和DDD是产品开发中非常互补的方法,有助于更好地理解需求和提高产品质量。 什么是TDD、BDD和DDD? BDD(行为驱动开发) BDD(行为驱动开发)是一种敏捷实践,由Dan North于2003年创建,旨在使用一种自然语言为所有人理解来创建功能测试。 但这个概念还更进一步,因为它能够使开发团队清楚地了解用户需求。例如,通常用于定义用户故事的“作为……以便”可能会导致模棱两可。这些验收标准(有些人称之为验收测试)在书写良好时可以消除所有对需求理解的疑虑。 这些验收标准以一种自然语言称为Gherkin的方式书写。以下是一个简单的示例: 假设我是产品页面上的客户当我单击产品ID“255”的“添加到购物车”时 并且库存为“3”那么产品将添加到购物车。 每个用户故事都将提供多个此类验收标准,以定义所有可能的行为,包括正面和负面情况。为了最大程度地减少这些测试的未来过时风险,不应包含实施。 通过与业务专家和用户一起在开发需求之前编写这些测试,团队将更有可能确保满足用户的实际需求,同时遵循可能的约束,如法律和业务约束。我将把这种方法称为未来功能的最佳切入点。 DDD(领域驱动设计) DDD是一种由Eric Evans于2003年引入的软件设计方法,其目标是使业务领域成为软件设计的支柱。DDD方法不会告诉您如何“编码”应用程序,但会引导您设计应用程序,以反映业务规则。 在这个方法中,我们仍然试图将产品设计的所有参与者聚集在一起,消除不同专业领域之间的壁垒。 这个方法带来了一些重要的好处: 消除业务和开发团队之间可能出现的任何模糊不清 设计软件以方便未来的调整 减少可能的回归问题 必须明白,各种类型的专家(业务、开发人员等)必须共同努力才能实现这种方法。 不久之后,我将发布几篇关于这种在软件工艺社区非常流行但在公司内部应用得还不是很多的方法的文章。的确,光在几行文字中理解DDD并不容易。 尽管这种方法与我们之前看到的BDD方法非常不同,但它与BDD方法完全互补。 我们通过BDD与业务共同获取需求(进一步明确期望) 我们使用DDD方法与业务的帮助下设计应用程序,以反映业务领域的复杂性 TDD(测试驱动开发) TDD(测试驱动开发)是一种软件开发方法,其目的是在编写函数的内容之前编写该函数的单元测试。这是持续集成领域非常知名的实践。 这种在XP、Scrum XP或DevOps领域中非常流行的做法的目标是在编写代码之前告诉您代码将面临的情况。这种实践从根本上改变了开发人员的经典思维。 尽管TDD增强了产品质量并减少了未来的回归问题,但“测试”的概念并不是它的主要功能。TDD主要用于引导开发人员找到测试中提出的需求的解决方案。 事实上,通过提前编写测试,开发人员将得到指导,以达到预期的解决方案。不再需要浪费时间来实现功能,存在着无法满足预期结果的风险。 尽管这种方法更加注重“开发”,但它也与我们之前看到的两种方法完全互补。 我们通过BDD与业务共同获取需求(进一步明确期望) 我们使用DDD方法与业务的帮助下设计应用程序,以反映业务领域的复杂性 我们通过TDD使用测试来巩固应用程序,减少未来回归问题,并根据每个单元函数的期望得到指导 结论:TDD、BDD、DDD […]