近年来，我只为大型项目或小型工具中的人员编写了小型组件。我从来没有编写过单元测试，而且似乎总是像学习如何编写它们并实际上使一个人测试花费了很多时间，而不是简单地启动程序并进行真实测试。
我将要开始一个相当大的项目，该项目可能需要几个月的时间才能完成，尽管我会像往常一样尝试在编写元素时对其进行测试，但是我想知道单元测试是否可以节省时间。
我只是想知道是否有人可以提供很好的建议：
Answers:
有人会说别的，但我建议您将TDD和单元测试分开。TDD是一个很大的思想转变，单元测试最初似乎需要时间。如果您将它们视为一项，则有可能无法立即看到足够的收益，并且有诱惑力将其简单地删除TDD和单元测试。
首先是编写一些单元测试。首先，它们不一定是完美的。只需自学一下如何测试少量代码，以及如何使用模拟来隔离组件。
这是最大的时间获取者，但迄今为止收益最大。一旦发现不再需要浏览14个网页即可转到要测试的网页，您就会知道我在说什么。
对我来说，尤里卡最重要的时刻是一个Windows应用程序，当时我试图测试一个正则表达式，要求我先填写两种表格才能使用它。我安装了NUnit并围绕该方法编写了一个测试，然后看到节省了数小时的测试时间。然后，我添加了更多测试来处理边缘情况。等等。
然后学习写好单元测试。了解快速编写的易碎测试与编写许多单独的测试之间的平衡。这很容易。经验教训是，理想情况下，每个测试只能测试一件事，但是您很快就会了解需要花多长时间，因此您开始对规则稍加调整，直到编写出每次代码更改都中断的测试，然后再回到正确的平衡（后者比后者更接近前者）。
正如我所说，TDD是您工作方式的重大精神转变。但是，一旦您已经编写了测试，就不会在开发过程中花费很多时间。我保证，您会看到自己的编码风格得到改善。或者更确切地说，如果您不放下它，那不适合您。
最后要记住的一点是，TDD不仅限于单元测试。验收测试驱动设计是TDD的一部分。另一个不要将它们混在脑海中的好理由。
我同意其他人的看法（绝对不要在最后编写您的测试，TDD需要花些时间学习，但可以尝试从测试开始，最终要争取完整的TDD）。但是我想补充一件事来回应您的评论：“我想知道单元测试是否可以节省我的时间。”
我的回答是明确的。在经过类似时间的无测试编码之后，我大约在10年前就学会了TDD方法。这些天，如果我正在做一些简短（<250 loc）和简单的事情，或者是一些一次性的事情，那么我就不会TDD了。否则，我这样做，恰恰是因为它节省了时间。
节省时间的方式有3种：减少WTF，减少调试和减少恐惧。第一个很明显：您花费更少的时间去思考所构建的东西到底在做什么。当您遇到问题时，调试会容易得多，因为a）您可以立即捕获经过测试的错误，并且b）未经测试的错误隐藏的位置更少。
恐惧感越小，它就越隐蔽。直到您花了一段时间在TDD代码库中，您甚至都没有意识到花费了多少时间担心所做的更改。X有效吗？它会破坏Y吗？是否有一些Z可能会受到影响？使用TDD，这种情况就消失了，因为您将恐惧变成了测试，然后计算机使担心的事情自动化了。勇敢的开发者是更快的开发者。
我是否应该一开始就考虑使用单元，并采用TDD方法。
在每个部分完成之后，我是否应该随手编写测试。
这些都可以，但不是第三种选择。
如@pdr所述，学习正确的单元测试需要时间。您绝对希望在项目生命周期的开始时花点时间学习，而不是在迫在眉睫的最后期限时花点时间学习。这样，您就已经可以加快速度，甚至可能由于截止到项目生命周期中的大多数错误而在截止日期临近时开始收获收益。
请注意，最开始的单元测试始终是最困难的，尤其是在测试已经编写的代码时。这样的代码可能不适合单元测试，因此您可能很难连接所有处于正确测试状态的对象。因此，为您的第一次单元测试尝试选择一些简单，相当隔离的低级别测试，然后逐渐增加挑战级别。一旦准备好第一个测试夹具，下一个测试用例就容易得多了，到第四个测试用例时，您将像在传送带上一样生产测试用例。从那时起，您开始感到能够重复进行，证明您的代码可以工作的好处...
我个人更喜欢TDD方法，但我认为这不是那么具有挑战性-确实需要毅力，但是我相信您越早开始使用TDD，就越早开始看到整体单元测试的好处。但是，可能是前几个单元测试最好针对已经拥有的代码进行编写。然后，一旦掌握了它，就可以开始尝试TDD。
我认为对于新手来说，最好的办法是解决一些有助于单元测试的代码选项。例如; 验证电子邮件地址。一旦您解决了其中一些Code Katas，TDD就成为自然的流程。请查看下面提到的代码代码，以获取我提到的电子邮件地址验证器： 电子邮件验证器
有关不认识的人的代码Katas的解释，请查看以下链接： Code Katas