unit-testing - TDD 与单元测试

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 8 年前。

Improve this question

我的公司对我们的代码进行单元测试还相当陌生。我阅读有关 TDD 和单元测试的内容已经有一段时间了，并且确信它们的值(value)。我试图让我们的团队相信 TDD 值得努力学习并改变我们对编程方式的思维方式，但这是一场斗争。这让我想到了我的问题。

TDD 社区中有很多人非常热衷于先编写测试，然后再编写代码(我也同意他们的观点)，但是对于一个正在与 TDD 作斗争的团队来说，妥协是否还能带来额外的好处？

一旦代码编写完毕(也许作为 checkin 代码的要求)，我可能会成功地让团队编写单元测试，并且我的假设是编写这些单元测试仍然有值(value)。

将陷入困境的团队引入 TDD 的最佳方式是什么？如果做不到这一点，即使是在代码编写之后，仍然值得编写单元测试吗？

编辑

我从中得到的结论是，在编码过程中的某个地方开始单元测试对我们来说很重要。对于团队中接受这个概念的人来说，首先开始更多地转向 TDD 和测试。感谢大家的意见。

跟进

我们最近开始了一个新的小项目，团队的一小部分人使用了 TDD，其余的人在代码之后编写单元测试。在我们完成项目的编码部分后，那些在代码之后编写单元测试的人惊讶地发现 TDD 编码人员已经完成并且具有更可靠的代码。这是赢得怀疑者的好方法。我们仍然面临许多成长的烦恼，但意志之战似乎已经结束。感谢所有提供建议的人!

Answer 1

如果团队在实现 TDD 方面陷入困境，但他们之前没有创建任何单元测试...那么在编写代码后通过创建单元测试来开始他们。即使在代码之后编写的单元测试也比没有单元测试好!

一旦他们精通单元测试(以及随之而来的所有内容)，那么您就可以让他们首先创建测试......然后编写代码。