关于测试驱动开发但反转

Question

我很欣赏TDD,并认为它是必不可少的,但只有在我编写源代码然后重构之后才能编写我的测试.我永远不会让自己先写测试然后通过测试来源.所以我总是扭转这个过程.这对我来说是不好的做法吗？和我一样反向做的有什么缺点？

Answer 1

如果你没有先写下你的测试,那么它可能不是TDD.使用TDD,您通常会编写测试,观察测试失败,然后执行以使其通过.

优于您的工作流程的优势是:

• 你的测试可能会失败!创建一个简单不会失败的测试太容易了.正如Eric所指出的那样,如果你不先写测试,看它失败,你怎么知道测试实际上是在测试你刚才实现的功能？
• 您的代码肯定是可测试的.虽然我确信您遵循可测试的技术,但测试第一个开发确保代码可以确定,否则您将不会编写代码:-)
• 将您的解决方案"颠倒".这是有争议的,但TDD会让你思考"你需要什么"而不是"实施细节".首先通过生成测试,将测试中的一般体系结构/类结构拼凑在一起,然后了解实现细节.

您可以降低所有这些点的风险,因此无论您是希望保持原样还是首先切换到测试,都取决于您.

Answer 2

如果您之后编写测试,他们真的会推动开发/设计吗？我不这么认为.

扩展Steven Robbins的答案:如果你的测试在通过之前没有失败,你怎么知道它正在测试正确的东西？