TDD

众

为什么我们不同意罗伯特·马丁的

测试驱动开发（TDD）是一种软件开发过程，依赖于短期开发循环的重复： 首先开发人员编写一个自动化测试用例来定义所需的改进或新功能， 然后编写代码来通过该测试， 最后重构新代码以符合可接受的标准。 然而，很

现在想想真是离谱，我一个学化学的居然干起了程序员！整天跟试管烧杯打交道的我，哪能想到最后会靠敲代码吃饭？你们能想象一个满脑子都是化学方程式的人，突然要跟电脑对话是什么画面吗？ 刚开始那会儿我可怂了，整整一年都不敢多写代码。天天就跟在别人屁股后面做测

如何将TDD与DDD结合起来，最近在看TDD（测试驱动开发的艺术），也按照书中例子尝试了一些，然而思维仍然很混论。感觉上无法很好的调和DDD和TDD，大体上感觉TDD应该遵从DDD中的原则和约束应用到代码中，然而这两者之间的过渡仍然不甚明了，如何将DDD渗入到TDD中，使用了TDD，直接从用户的需求

熟悉TDD的三个定律这些规则是在实践中使用TDD的基础。它们限制我们一次只更改一件事。他们迫使我们采取步伐！记住并严格遵守这些规则，以便有效地使用TDD！在代码没有通过失败的单元测试之前不要编写任何生产代码。没有遭遇更多失败还有编译错误之前不允许编写更多的单

TDD揭示现实背后的肮脏真相：几乎所有LoB应用程序（数据库应用）都无法使用TDD，因此LoB无需任何有趣或艰苦的工程设计。 众说纷纭：如果我们的顾问只知道SQL，将我们所有的应用程序逻辑塞入2000行存储过程中，没人会维护它。寄生虫经理会

在2010年至2014年期间，我正在开展一个名为http://mes-courses.fr的辅助项目。这实际上类似“家庭购物”。我希望人们能够在5

如果您正在使用测试驱动开发，请不要衡量单元测试的代码覆盖率，这比无用的统计更糟糕; 它会积极地引导你误入歧途。你应该怎么做？这取决于你想要完成什么。 改进代码和测试实践如果您正在尝试改进团队的编码和

TDD并不意味着先编写测试，然后编写代码。它的意思是“编写测试的一部分，编写代码的一部分。” （然后反馈、改进和重复。） 众说纷纭：TDD是设计软件的一种糟糕方法！ 如果您的代码设计合理，并且有良好的人员在工作，则代码库或团队的规模并不重要，则不需要测

首先从编写测试的最后一部分开始：从期望（或断言）开始，然后自下而上编写测试。在最后开始测试，期望（或断言）的位置可能会让人感到奇怪。您可能倾向于从上到下编写测试，从设置到调用生产代码，再到期望。从期望开始可能会感觉不对。把它想象成写一份报告——你可能记得在学校时必须写报告：一