是否应该在编写代码之前编写单元测试？

我知道测试驱动开发的定义原则之一是你首先编写单元测试,然后编写代码来通过这些单元测试,但是有必要这样做吗？

我发现在我写这篇文章之前,我经常不知道自己在测试什么,主要是因为过去我参与过的几个项目都是从概念验证而不是设计而来的.

我之前尝试过编写单元测试,它可能很有用,但对我来说这似乎并不自然.

这里有一些好的评论,但我认为有一件事被忽略了.

编写测试首先驱动你的设计.这是重要的一步.如果您"同时"或"不久之后"编写测试,您可能会遗漏一些微步骤TDD的设计优势.

一开始感觉真的很俗气,但是在你眼前看到的东西展现出你原本没想到的设计真是太神奇了.我已经看到它发生了.

TDD很难,并不适合所有人.但如果您已经接受了单元测试,那么试试一个月,看看它对您的设计和生产力有何影响.

您在调试器中花费的时间更少,并且更多时间考虑外部设计.这是我书中的两个巨大的优点.

已经有研究表明,在编写代码之后编写的单元测试是更好的测试.但需要注意的是,人们不会在事件发生后写下这些内容.所以TDD是一个很好的折衷方案,至少测试得到了解决.

因此,如果您在编写代码后编写测试,对您有好处,我建议您坚持下去.

我倾向于发现我做了一个混合物.我越了解这些要求,我就可以写出更多的测试.当要求 - 或者我对问题的理解 - 很弱时,我倾向于在之后编写测试.

TDD不是测试,而是测试如何驱动代码.所以基本上你是在编写测​​试来让架构自然地进化(并且不要忘记重构!!!否则你不会从中获得很多好处).你之后拥有一系列回归测试和可执行文档是一个很好的副作用,但不是TDD背后的主要原因.

所以我的投票是:先测试一下

PS:不,这并不意味着您之前不必计划您的架构,但如果测试告诉您这样做,您可能会重新考虑它!

在过去的6到7年里,我一直领导开发团队.我可以肯定的是,作为一名开发人员和我曾经合作过的开发人员,如果我们知道我们的代码在大局中的位置,它会对代码的质量产生显着的影响.

测试驱动开发(TDD)帮助我们回答"什么？" 在我们回答"怎么样？"之前 它会产生很大的不同.

我理解为什么可能会担心在PoC类型的开发/架构师工作中不遵循它.你是对的,它可能没有完全意义来遵循这个过程.同时,我想强调TDD是一个属于开发阶段的过程(我知道它听起来已经过时了,但是当低级规范明确时,你明白了.)