TDD与单元测试
我的公司对单元测试我们的代码是相当新的。 我一直在阅读TDD和单元测试一段时间，并确信它们的价值。 我试图说服我们的团队，TDD值得努力学习和改变我们对计划的思维方式，但这是一场艰苦的斗争。 这使我想到了我的问题。
TDD社区有很多人对编写测试和代码非常虔诚（而且我和他们一起），但对于一个正在与TDD苦苦挣扎的团队来说，妥协还是会带来额外的好处？
一旦编写代码，我可能成功地让团队编写单元测试（也许作为签入代码的要求），我的假设是编写这些单元测试仍然有价值。
将艰苦的团队带入TDD的最佳方式是什么？ 如果失败了，即使在编写代码之后仍然值得编写单元测试吗？
编辑
我从中取走的是，在编码过程中的某个地方启动单元测试对我们来说非常重要。 对于那些接受这个概念的团队来说，开始进一步走向TDD并首先进行测试。 感谢大家的意见。
跟进
我们最近开始了一个新的小型项目，其中一小部分使用了TDD，其余的则在代码之后写了单元测试。 在我们结束了项目的编码部分之后，那些在代码之后编写单元测试的人惊讶地发现TDD编码器已经完成并且具有更坚实的代码。 这是赢得怀疑者的好方法。 我们仍然有很多成长的痛苦，但遗嘱战似乎已经结束。 感谢所有提供建议的人！
如果团队在实施TDD时遇到困难，但他们在......之前没有创建任何单元测试，那么在编写代码之后通过创建单元测试来启动它们。 即使在代码之后编写的单元测试都比没有单元测试更好！
一旦他们精通单元测试（以及随之而来的一切），那么你可以努力让他们首先创建测试，然后编写第二个测试。
编写代码后，写入单元测试绝对值得。 只是有时候它通常比较难，因为你的代码没有设计成可测试的，而且你可能已经过度复杂了。
我认为将团队纳入TDD的一条实用的好方法是在过渡期或可能长期提供“开发中测试”的替代方法。 他们应该被鼓励参与TDD对他们来说很自然的代码部分。 然而，在看起来难以接近测试的代码段或者使用由非敏捷A＆D过程预先定义的对象的代码段中，开发人员可以选择编写一小段代码，然后编写测试以涵盖代码，并重复这个过程。 在编写代码之后立即编写单元测试某些代码比根本不写任何单元测试要好。
在我看来，最好有50％的测试覆盖率，“代码优先，测试完成”和100％完成的库，测试覆盖率超过100％，完成了TDD的库50％。 过了一段时间，您的开发人员希望能够为他们编写的所有public代码编写测试，从而获得娱乐性和教育性，因此TDD将潜入其开发过程中。
上一篇: TDD vs. Unit testing