任何人都可以推荐一些关于如何解决开始对大型现有代码库进行单元测试的问题的最佳实践吗？ 我目前面临的问题包括：
显然，我知道我应该从重构代码开始，以减少耦合，并提高可测试性。但是，如果没有 UnitTests（鸡和蛋，有人知道吗？），进行这样的重构是有风险的。
顺便说一句，您是否建议在域类或层类（日志记录、实用程序等）上开始重构和编写测试？
【问题讨论】：
标签： unit-testing refactoring legacy-code
首先，我赞同 Jeffrey Frederick 给出的“有效使用遗留代码”的建议。
正如您在问题中所述，您无法更改代码，因为您目前没有可用于检测回归的单元测试，并且您无法添加单元测试，因为您的代码库不可单元测试。在这种情况下，您可以创建characterization tests：端到端自动测试，帮助您检测软件外部行为的变化。一旦这些到位，您就可以开始慢慢修改代码。
但是，对庞大的代码库进行测试是一项巨大的工作，而且风险很高，而且这样做可能会让团队精疲力竭，因为他们必须付出巨大的努力，而在测试覆盖率方面回报却很低。对整个代码库进行测试是一项永无止境的工作。
相反，从代码库中开发新功能，这样它就不会妨碍您。新代码经过全面测试后，将其集成到代码库中。
每次修复代码库中的问题时，也要尝试创建单元测试。第一次会很困难，但是一旦您准备好设置一些单元测试环境，它就会变得更容易。
【讨论】：
缺乏写作经验 单元测试/TDD
我认为这是最重要的。
标准建议是首先开始为所有新代码编写单元测试，以便在尝试对现有代码进行单元测试之前了解如何进行单元测试。我认为这是理论上的好建议，但在实践中很难遵循，因为大多数新工作都是对现有系统的修改。
我认为，如果你能获得“球员教练”的帮助，你会得到很好的服务，他可以与你的团队一起开展项目并在应用它们的过程中教授技能。
而且我认为我有法律义务告诉您获取 Michael Feather 的Working Effectively with Legacy Code。
【讨论】：
在 Johanna Rothman 的书 Manage it! 中有很好的建议。
我还可以推荐以下内容：
单个单元测试无济于事。但它需要开始。之后，将对应用程序中风险最大的部分进行少量单元测试，这将有助于防止这些部分中的错误。到了这一点，大多数开发人员都会意识到单元测试的用处。
【讨论】：
你不会靠自己的力量把这件事做好。 需要很多说服力。所以我想给你这个帖子，其中提供了很多信息和良好论证的提示：How do you persuade others to write unit-tests?
只有整个团队才能创建如此庞大的单元测试。
【讨论】：
毛。我也不得不处理这个。我认为，最好的办法是大量依赖最初可能不想使用的令人讨厌的工具（如 NUnitAsp）来测试现有代码。然后你就可以开始重构了，而这些工具可以防止你的代码库在你手下分崩离析。
然后，当您重构时，在您正在创建的新的、可测试的部分上编写更多逻辑单元测试，并逐渐淘汰原始测试。
【讨论】：
祝你好运... 由于您几乎没有编写单元测试的经验，我建议您首先尝试至少获得一些经验。否则，您很可能会放弃 TDD/单元测试，并且可能会在您尝试进行单元测试的系统中引入新的错误。 获得经验的最好方法是找一个有经验的人来帮助你。
【讨论】：