任何人都可以推荐一些最佳实践，以解决如何开始对现有的大型CodeBase进行UnitTest的问题吗？我目前面临的问题包括：
显然，我知道我应该从重构代码开始，以减少耦合，并提高可测试性。但是，如果没有UnitTests（Chicken和Egg，有人吗？），进行这种重构是有风险的。
附带说明，您是否建议对Domain类或层类（日志记录，实用程序等）开始重构和编写测试？
[首先，我第二次推荐Jeffrey Frederick提出的“有效使用旧版代码”。
正如您在问题中所指出的，您无法更改代码，因为当前没有可用于检测回归的单元测试，并且您无法添加单元测试，因为您的代码库不可用于单元测试。在这种情况下，您可以创建characterization tests：端到端自动测试，以帮助您检测软件的外部行为中的变化。一旦安装到位，您就可以开始缓慢地修改代码。
但是，对您的HUGE代码库进行测试是一项巨大的工作，风险很高，您可能会精疲力竭，因为这样做他们将不得不付出巨大的努力，而在测试覆盖率方面却付出了低回报。对整个代码库进行测试是不懈的努力。
相反，从代码库开发新功能，这样就不会妨碍您。新代码经过全面测试后，将其集成到代码库中。
此外，每次在代码库中解决问题时，都要尝试创建单元测试。第一次很难，但是一旦您准备好要设置一些单元测试环境，它将变得更加容易。
缺乏写作经验UnitTests / TDD
我认为这是最重要的。
[标准建议是先开始为所有新代码编写单元测试，以便在尝试对现有代码进行单元测试之前，您将学习如何进行单元测试。我认为这在理论上是不错的建议，但在实践中很难遵循，因为大多数新工作都是对现有系统的修改。
[我认为您可以与“球员教练”联系，因为他可以与您的团队一起从事该项目并在应用他们的过程中传授技能。
而且我认为我有法律义务告诉您获得Michael Feather的Working Effectively with Legacy Code。
[Johanna Rothman在Manage it!书中有很好的建议。
您不会自行解决此问题。有很多说服力。因此，我想为您提供这个线程，其中提供了许多信息和良好论证的提示：How do you persuade others to write unit-tests?
总我也不得不处理这个。我认为，最好的方法是首先依赖您可能不想使用的讨厌的工具（例如NUnitAsp），以对现有的代码进行测试。然后，您可以开始重构，而那些工具可以防止您的代码库从您的手中跌落。
祝你好运...由于您几乎没有编写单元测试的经验，因此建议您首先尝试至少获得一些经验。否则，您可能会放弃TDD /单元测试，并可能在要进行单元测试的系统中引入新的错误。获得经验的最佳方法是找到有经验的人可以为您提供帮助。