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