有人可以推荐一些关于如何解决启动UnitTest大型现有CodeBase问题的最佳实践吗？ 我目前面临的问题包括：
显然，我明白我应该从重构代码开始，使它更少耦合，更可测试。但是，没有UnitTests（鸡和鸡蛋，任何人？），进行这样的重构是有风险的。
另外，您是否建议在Domain类或层次类（日志记录，实用程序等）上启动重构和编写测试？
答案 0 :(得分：11)
首先，我推荐Jeffrey Frederick给出的“有效使用遗留代码”的建议。
正如您在问题中所述，您无法更改代码，因为您目前没有可用于检测回归的单元测试，并且您无法添加单元测试，因为您的代码库不是单元可测试的。在这种情况下，您可以创建characterization tests：端到端自动测试，以帮助您检测软件外部行为的变化。一旦到位，您就可以开始慢慢修改代码。
但是，将您的巨额代码库置于测试之下是一项巨大的努力，风险很高，而且您可能会让团队在执行此操作时耗费精力，因为他们必须在测试覆盖率方面做出强有力的努力并获得低回报。将整个代码库置于测试之下是一项无穷无尽的努力。
相反，从代码库开发新功能，这样它就不会妨碍你。完成新代码测试后，将其集成到代码库中。
每次修复代码库中的问题时，也会尝试创建单元测试。这将是第一次很难，但一旦你准备好设置一些单元测试环境，它会变得更容易。
答案 1 :(得分：7)
缺乏写作经验 单元测试/ TDD
我认为这是最重要的。
标准建议是首先开始为所有新代码编写单元测试，以便在尝试对现有代码进行单元测试之前学习如何进行单元测试。我认为这在理论上是很好的建议，但在实践中很难遵循，因为大多数新工作都是对现有系统的修改。
我认为通过访问“玩家教练”可以获得良好的服务，他可以与您的团队合作完成项目并教授应用过程中的技能。
而且我认为我有法律义务告诉你让Michael Feather Working Effectively with Legacy Code。
答案 2 :(得分：5)
Johanna Rothman在书Manage it!中提出了很好的建议。
我还可以重申以下内容：
单个单元测试无济于事。但它需要开始。之后，将对应用程序中最危险的部分进行一些单元测试，这将有助于防止这些部分中的错误。当你到达这一点时，大多数开发人员将意识到单元测试的有用性。
答案 3 :(得分：1)
你不会自己做这件事。 需要很多说服力。所以我想给你这个帖子，其中给出了很多关于良好论证的信息和提示：How do you persuade others to write unit-tests?
只有整个团队才能创建如此大规模的单元测试。
答案 4 :(得分：0)
毛。我也必须处理这个问题。我认为，最好的办法是尽量使用你可能不想使用的令人讨厌的工具（如NUnitAsp），以便在测试中获得现有代码。然后你就可以开始重构了，而这些工具可以防止你的代码库从你身边消失。
然后，当您重构时，在您正在创建的新的可测试部分上编写更多逻辑单元测试，并逐渐退出原始测试。
答案 5 :(得分：0)
祝你好运...... 由于您在编写单元测试方面经验不足，我建议您首先尝试获得至少一些经验。否则，您可能会进行TDD /单元测试，并可能将新错误引入您尝试进行单元测试的系统中。 获得经验的最佳方式是找到有经验的人来帮助你。