在查看和行为驱动开发时,“行为驱动开发是测试驱动开发的扩展”(来自维基百科)。围绕各种文章进行研究,行为驱动开发是TDD的一种形式,即编写单元测试。同时,BDD关注的是业务价值,但并不是所有模块都能独立提供直接的业务价值。(在嵌入式软件开发中,这通常是正确的。)只有当单独的模块一起使用时,才会增加业务价值。因此,关注于业务需求的行为测试可以使用单元测试来实现,这似乎是矛盾的。
行为驱动的开发是否在为单个单元编写单个单元测试的级别上工作。或者它实际上与集成测试有更密切的关系,跨越多个单元?
举个例子:如果低级组件本身没有提供任何业务价值,那么如何为低级别模块(如内存访问模块或组件驱动程序)编写行为驱动的“单元测试”?
然后,在另一个方向上,如果业务需求只能在集成低级别模块时才能被验证,而不能使用低级模块的模拟来验证,那么如何为单个高级组件编写行为驱动的“单元测试”呢?
相关问题,但没有完全区分BDD和TDD:如何在使用BDD时使用单元测试?
发布于 2021-08-11 15:29:23
TDD是由专注于行为的人发明的。那些人看到它起飞并变得流行起来。一旦它流行起来,它就落入了那些从结构上考虑TDD的人的手中。TDD结构人员不允许您在没有在测试中包装类的情况下创建类。他们创建了颠覆可访问性修饰符的方法,这样他们就可以模拟这个类所协作的所有其他类,而不管协作者是慢的还是非确定性的。任何可以在单元测试框架下运行的测试都被称为单元测试。这支部队总是一个班。
BDD是由专注于行为的人发明的。这些人希望,如果他们能更好地解释同样的想法,人们就不会像TDD背后的想法那样破坏它。这一次似乎效果更好。然而,它的存在似乎并没有阻止结构性的TDD人。
如果你不同意上面的说法,那就好了。在我看来就是这样。不过,记住这一点,因为这是我在处理你提出的问题时所看到的镜头。
如果你想成为行为者之一,那么我请你考虑重构。每一个好的测试都是通过一些接口进行的,并期望有一些行为。即使接口后面的实现完全改变了,该测试也应该通过。只有当您不坚持测试私有函数、抽象的对象/类或其他只有在接口抽象之后才能看到的实现细节时,这才有效。通过这种方式进行测试,重构只会在重新设计接口时使测试失败。
如果你想成为一个结构性的人,我真的没有一个好的答案。当你以这种方式工作和思考时,BDD是没有意义的。它的目的是不。
对于行为者,TDD和BDD的解释是相同的。一个单位不是你语言的某种结构。这是你画的边界。在其中,您希望代码具有确定性和快速性,以便您的测试是可靠的和可执行的。调用多少方法或引用对象并不重要。这些是实现细节。代码的高低并不重要。这些是实现细节。
给定一个需求列表和一个未经测试的公共方法列表,人们的行为将集中在需求上。就像私有方法可以通过公共方法调用来获得它们的代码覆盖一样,挂在其他对象抽象的对象上的公共方法也是如此。
在一个足够复杂的代码库中,在测试单元中使用测试单元比用测试提供的示例解释代码更有用。但这是个微妙的陷阱。这是一个为了代码而存在的测试。不是生意上的需要。满足业务需要的其他方式,然后代码,及其测试,不再需要存在。测试(因为人们不理解测试不是直接支持需求)而保留不需要的代码的测试,最终可能会阻止所需的重构。
业务价值来自于特性。不是密码。如果我能拥有所有的功能而没有代码,我会喜欢的。因为功能是用来支付账单的。不是密码。在编写测试时,请关注所需的功能。不是你的密码。
发布于 2021-08-11 16:09:59
测试水平(单元、集成、系统)和测试策略(应用TDD和/或BDD)是正交的。
通常,TDD被认为是在单元测试级别,有时是集成测试级别。然而,这不一定是必要的。例如,验收测试驱动开发(ATDD)处于系统和验收级别。TDD主要是使用测试来指导(或驱动)开发。首先是失败的测试,定义系统应该能够实现的功能,然后实现系统实现该目标所必需的功能。
BDD是对TDD的扩展,与TDD一样,它可以应用于任何级别。BDD的重点是通过测试使系统的预期行为透明化。任何测试方法都可以用来实现TDD,因为它是面向开发人员的。BDD将测试公开为使用特定域语言指定系统行为的一种方式。
这意味着BDD需要TDD,因为行为驱动的测试驱动开发。如果测试是在代码之后编写的,那么人们可能会认为开发不是由测试驱动的。但是,即使在编写代码之后,仍然可以以一种强调系统行为的方式编写测试。
因为在BDD测试中捕获的行为通常是从用户的角度出发的,所以它们很可能是系统级的测试。但是,没有什么可以阻止技术人员使用BDD风格的测试来捕获单元或单个类和方法的行为。
使用BDD框架和使用BDD也有区别。因为BDD意味着TDD,所以说使用BDD意味着在编写代码之前以一种面向行为的方式编写测试。但是,测试框架并不会强制这样做。人们可以在编写代码之后编写BDD风格的测试,使他们所做的事情不是BDD。
所有这些决定都是团队应该做出的决定。团队想要使用TDD吗?创建BDD风格的测试有意义吗?应该在什么级别使用TDD?在所有级别的测试中使用BDD测试框架是否有意义?对这些问题的回答可以通知团队在对他们的过程和工具做出决策时。
发布于 2021-08-12 03:55:47
TDD和BDD是非常简单的话题,但围绕着它们却有太多的混淆。比如BDD与TDD的一些关系。没有,它们是完全正交的。类似@ reference,我想参考丹·诺斯关于BDD是如何创建和开发的的文章--如果你想知道真实的故事,值得一读。
BDD作为测试的命名约定开始。而不是说“测试这个和那个”,你现在说“这个和那个工作”。就这样。稍后,作者认为将其扩展到团队中的其他角色(如业务分析师)是个好主意。但到目前为止似乎还不起作用。
TDD只是编写测试、编写生产代码和重构的顺序。我更详细地介绍了TDD和BDD之间的区别,这里。
无论是编写单元测试还是更高级别的测试,都可以是关于行为的。行为并不意味着这与生意或金钱有关。如果它是一个内存管理代码,您的测试可能会说“如果没有引用对象,则会释放GC内存”--这是BDD命名测试的一个例子。
https://softwareengineering.stackexchange.com/questions/430977
复制相似问题