我有一个项目已经在做了一段时间，它只是一个我希望有一天能够开源的小项目。
我大约12个月前开始着手这个项目，但当时只是轻微地工作。直到最近，我才开始更加集中地投入大量的时间(几乎每晚)。
由于它是一个类似框架的应用程序，有时我会因为没有任何东西来驱动我的设计决策而感到迷茫，导致我有时会制作出难以使用甚至难以找到的功能。我一直在阅读关于如何进行TDD的文章，想着也许这可以帮助我解决一些问题。
所以问题是，你认为在一个还没有使用TDD的项目上开始使用TDD是个好主意吗？
编辑：我刚刚添加了一些内容来澄清我所说的“感到迷茫”，这可能不是没有澄清就说的最好的话。
在我看来，采用更好的实践或放弃更差的实践永远都不会太晚，所以我会说“是的，你应该开始”。
然而......（总会有一个“但是”）...
...... TDD最大的收获之一是影响了你的设计，鼓励你保持责任分离、交互干净等方面。
在项目的这个阶段，你可能会发现很难为框架的某些方面编写测试。但不要放弃，即使你不能测试某些区域，你可以通过测试其它区域提升质量，并因此提高技能水平。
是的。
基本上，您可以通过为任何新代码以及对现有代码进行的任何更改添加TDD来避免任何危害。显然，回溯并为现有代码添加准确的测试可能会比较棘手，但是覆盖主要用例肯定不会有坏处。
也许考虑看一下.NET中的棕地应用程序开发？其中充满了针对这种情况（“没有适当的单元测试”之一的定义）的实用和实践建议。
是的，开始实行测试驱动开发(TDD)绝对是个好主意。
你需要进行一些启动成本，至少有以下两个原因：
你需要做这两件事情，但是在工作时，如果你发现自己很吃力，请考虑哪个是努力的源泉。
但最终结果是值得的。从你所描述的情况来看，这是一个你打算长期使用的项目。请记住，当你失去一小时或者更多时间时，这些投资都将在一年后得到回报，你会非常高兴你拥有这样的技能和代码库。
正如其他人所说，TDD不应该对正在进行的项目造成伤害，但是如果你想做大规模的重构以便于测试，一定要认真考虑。确保好处超过成本。
我有点担心你“缺乏方向感”。我不知道TDD是否能帮助你。我发现它对低级别的设计决策非常有帮助，但对架构决策并不那么有帮助。在没有方向的项目中添加TDD，听起来有点像为了挽救婚姻而生孩子-不明智。希望我误解了你的意图。
是的。
TDD让其他人更容易理解代码，也使应用程序随着时间的推移具有更好的设计。
理论上你应该先进行测试，但你没有。在这种情况下，与其他人的观点相反，我不会从新功能开始。
警告：放置测试用例将需要重构，这意味着您必须修复未出现故障的东西。
如果您仍然喜欢单元测试，那么您可以自己进行红色、绿色、重构。
当然可以。
在编写新代码时引入TDD，如果时间允许，可以使用“注释驱动设计”来测试现有代码（如果尚未进行测试）。
编写针对您不计划更改的现有工作代码的测试与TDD的主旨不符，TDD的主旨是编写可让您了解正在构建的系统的测试。
我引入TDD的方法是：
为与更改的代码相关的代码编写测试也可能会有益 - 例如，如果要更改父类，则可能需要先构建围绕子类的测试，以保护自己免受潜在损坏。
