它们应该涵盖所有小功能，还是更多适合自己的路径风格？
#1 楼
我建议您在需要重构遗留代码区域时回去进行那些单元测试。此问题中描述了执行此操作的方法。使用没有单元测试的遗留代码时，无论是否进行TDD，都采用相同的原理和技术来添加它们。有效地使用旧版代码
评论
推荐书+1时，我认识的一些开发人员强烈推荐它。我会在您的代码中进行快速搜索，以查找可能利用您正在修改的对象/类/方法等的任何其他内容，并添加反映那些东西首先（并确保它们通过）期望的行为的单元测试。然后针对新功能或要修复的错误编写单元测试。这样可以更好地防止因更改而破坏现有功能。
– Chuck van der Linden
2011年6月23日下午5:27
#2 楼
否。测试影响设计为时已晚，因此您无法获得TDD的主要好处。但是，您可以做的是在编写代码时编写测试。 。假设您使用的方法过长。假设其中一小部分已被提取为一种新方法，请编写一份测试。现在提取该方法。或说出现了错误报告；这是一个改进设计的机会（顺便说一下，您的测试范围也是如此）。编写一个演示该错误的回归测试。研究您的代码以了解该错误的根本原因。现在编写一个好的单元测试，以表达该根本原因应如何表现。通过该测试，如果操作正确，则回归测试也将通过。
TDD测试确实需要（a）提前进行； （b）在时间上与他们正在测试的代码非常接近。因此，接受“为了TDD”而改写代码为时已晚。养成习惯。通过上面概述的实践，需要测试的代码即可得到它们。
#3 楼
如果您将目标代码覆盖在即将发布的版本中被更改的可能性更高的区域，那么用单元测试覆盖现有代码可能是值得的。这样，您将围绕可能会更改的代码（新功能，重构，错误修复等）建立安全网。
针对具有更高逻辑复杂度的代码并将其用单元测试覆盖将提供更高的投资回报，因为与单元测试相比，在单元测试中更容易发现（更快/更容易）该代码中引入的错误系统或集成测试。
#4 楼
关键问题是您能承受它出毛病的负担吗？答案通常取决于您解决问题的速度如何-调试直到生产出来。虽然这不是一个好地方，但是对于某些一旦完成的事情，永远都不需要重新考虑。您可以不用任何测试就摆脱困境。
如果您的业务/生活取决于它的工作或工作出错，将很难修复（奔腾的bug），然后确定您触摸的任何地方都应该放置适当的测试安全网。
如果出错并没有关系，不用担心专注于真正重要的部分。
#5 楼
我建议您实施那些单元测试。 TDD是确保您的代码/功能实现按预期工作的一种方法，即使这意味着遗留代码。从好的方面来说，添加单元测试可能会帮助您发现意外的错误，除了为您提供重构代码的机会。牢记论点的实践方面，即实施成本。鉴于还有其他工作，这可能成为障碍。因此，最好采用渐进的方法来引入这些单元测试。可能是您可以根据重要性组织功能。质量保证服务中的以下链接可能对您有所帮助，https://blog.qasource.com/8-ways-to-succeed-with-agile-qa/
https://blog.qasource.com/resources/software-testing-process-in-agile-development-what-works-best
评论
如果执行TDD，则将具有单元测试，但这并不意味着所有单元测试都是TDD的结果。我看不到单元测试是一件坏事的情况。