TDD与单元测试
我的公司对我们的代码进行单元测试还是个新手。我读到TDD和单元测试已经有一段时间了，我相信它们的价值。我试图说服我们的团队，TDD是值得我们努力学习和改变我们如何编程的心态的，但这是一场斗争。这就引出了我的问题。
在TDD社区中有许多人非常热衷于编写测试和代码(我和他们一样)，但是对于一个正在为TDD而苦苦挣扎的团队来说，妥协还能带来额外的好处吗？
一旦代码编写完成，我可能会成功地让团队编写单元测试(也许作为签入代码的要求)，我的假设是，编写这些单元测试仍然是有价值的。
将一个苦苦挣扎的团队带入TDD的最好方法是什么？如果做不到这一点，那么即使是在编写代码之后，编写单元测试仍然值得吗？
编辑
我从中学到的是，在编码过程中的某个地方开始单元测试对我们来说很重要。对于团队中那些接受了这个概念的人来说，开始更多地转向TDD和测试。感谢大家的意见。
后续
我们最近开始了一个新的小项目，团队中的一小部分人使用了TDD，其余的人在代码之后编写了单元测试。在我们完成了项目的编码部分后，那些在代码之后编写单元测试的人惊讶地看到TDD编码器已经完成了，并且使用了更可靠的代码。这是一个赢得怀疑者支持的好方法。我们前面还有很多成长的烦恼，但意志之战似乎已经结束。感谢所有提供建议的人！
回答 17
Stack Overflow用户
发布于 2009-11-16 21:59:20
如果团队在实现测试驱动开发方面举步维艰，但他们没有创建任何单元测试before...then，那么就在编写代码后创建单元测试。即使是在代码之后编写的单元测试也比根本没有单元测试要好！
一旦他们精通单元测试(以及随之而来的一切)，您就可以让他们第二次创建测试first...and代码。
Stack Overflow用户
发布于 2009-11-16 21:58:20
在编写代码之后，编写单元测试绝对是值得的。只是有时候它通常更难，因为你的代码不是被设计成可测试的，你可能把它变得过于复杂了。
我认为，将团队引入TDD的一个很好的务实方法是在过渡期或长期提供另一种“在开发期间进行测试”的方法。应该鼓励他们使用TDD代码中对他们来说很自然的部分。然而，在看起来很难以测试为主的代码部分中，或者在使用由非敏捷A&D过程预先确定的对象时，开发人员可以选择编写一小部分代码，然后编写覆盖该代码的测试，并重复此过程。在编写代码之后立即为某些代码编写单元测试，总比根本不编写单元测试要好。
Stack Overflow用户
发布于 2009-11-16 21:58:01
在我看来，最好是用“代码优先，测试后”的50%测试覆盖率和100%完成库，而不是100%的测试覆盖率和50%完成库的TDD。过一段时间后，您的开发伙伴将有希望发现为他们编写的所有public代码编写测试是一件有趣且有教育意义的事情，因此测试驱动程序将悄悄进入他们的开发例程。
https://stackoverflow.com/questions/1742323
复制相似问题