TDD:单元测试焦点

虽然在某些对TDD的解释下,这可能是可能的,但我认为TDD的要点是在 任何 生产代码。既然如此,你就不会 有 为其编写集成或功能测试的大型系统,因此测试必须在单元级别上进行。

Behavior-Driven Development (BDD)在集成测试和功能测试级别应用TDD的思想。

TDD的红绿重构周期应该很快,非常快。快速反馈让你保持最佳状态。我见过TDD的方法,它采用完整的故事,将其表示为测试,然后驱动开发通过那个(大型ISH)测试。它名义上是TDD(或者可能是BDD),但对我来说并不合适。小步骤,单元测试,就是我如何学习TDD,我如何看待它,以及它如何最适合我。

从技术上讲,TDD是一种做事情的方法,而不仅仅是单元测试,理论上它应该驱动所有的开发过程。

理论上,原则是测试驱动开发,对于更复杂的场景,比如系统之间的集成,您应该定义集成测试,然后编写代码来通过这些集成测试(即使测试不是自动化的)。

当然可以。TDD依赖于自动化测试,这与测试的“类型”是一个正交关系。

如果你专注于想法,而不是技术实现,那么是的。我要说的是,如果,就一会儿,你忘记了 单元 测试,并将重点放在先编写测试的思想上,然后再编写实现,以便实现比在系统级别上更清晰的设计。

想象一下,您有一些需求。基于此,您可以编写用户验收测试——在捕获功能的高级测试。接下来你开始开发——你已经有了UAT测试形式的用例。您完全知道期望的是什么,因此更容易实现所需的功能。

另一个例子是基于Scrum的项目。在计划会议中,您讨论/创建/拥有稍后在Sprint期间开发的用户故事。这些用户故事实际上可以是UAT测试。

无论如何,我认为TDD是预先指定设计的方式,而不是应用程序测试周期/阶段/方法。之所以将TDD视为单元测试的同义词,是因为单元测试尽可能接近开发人员。对于开发人员来说,它们似乎是表示类/方法的功能设计的自然方式。

当然!TDD根本不需要单元测试。不幸的是,这似乎是一个常见的误解。

对于一个具体的例子,我完全驱动开发一个开源的嘲讽库(Java)。 整合 测验。我不为内部类编写单独的单元测试。相反,对于每个新特性或增强,我首先添加一个失败的验收(集成)测试,然后更改或添加到现有的生产代码,直到测试通过。在最终重构步骤中,这是纯TDD,即使没有 单元 测试被写入。