我目前正在与另一名合作学生一起完成一个即将完成的项目的合作项目。由于该项目已从合作社传递到合作社，因此沿途采取了不良做法，并将测试留到最后。我决定写单元测试来在测试时学习新东西。
但是，我正在开发一个 3 层、紧密耦合的应用程序，它似乎无法以当前形式进行单元测试。我不想通过一夜之间重构无法识别的代码来甩掉其他对这些概念一无所知的合作学生。那么我应该采取哪些步骤来慢慢地将代码拉向单元可测试性呢？我应该先实现一个工厂模式，然后让其他学生熟悉它，然后再继续前进吗？
如果我的知识有缺陷并且不应该有任何问题，我深表歉意。我是新手:)
Michael Feathers有效地使用遗留代码
很难知道实现工厂模式是否有任何好处，这取决于代码在做什么:)
Michael Feathers 的《有效使用遗留代码》（如果您订阅了 Safari，也可以使用）是完成任务的绝佳资源。作者将遗留代码定义为没有单元测试的代码，并且他给出了许多保守技术的实际演练——这是必要的，因为你在没有安全网的情况下工作——以便对代码进行测试。目录：
在项目的中途开始新的开发实践是非常困难的。过去，当我从事从一开始就没有进行单元测试的项目时，一个好的方法是制定“新代码必须有单元测试”的规则，但不要对单元测试施加压力为旧代码编写。
当然，当项目的结构不适合可测试性时，即使这样也很困难。
我最好的建议是采取小步骤。
首先创建没有测试的单元测试程序集（或项目或其他）。然后找到一个定义和分离得相当好的代码的小区域，并为该区域编写一些单元测试。让你的 co-coder 也来看看，并开始获得一些“最佳实践”，比如每次签入任何代码时运行单元测试（如果可能，自动运行）。
一旦你有这个工作，你可以慢慢开始添加更多。
关键是慢慢来。就像我说的，从一开始就让旧代码免于测试更容易。一旦您的团队掌握了单元测试的想法并且在编写它们方面变得更好，您总是可以稍后再返回它。
围绕代码中的主要功能编写一系列黑盒测试怎么样？由于您提到它是一个 ASP.NET 项目，因此您可以使用WaitN或Selenium等框架来自动化 Web 浏览器。这为您提供了一组基线功能，无论代码更改多少，该功能都应保持不变。
一旦你有足够数量的测试来测试你项目的高级功能，我就会开始深入研究代码，正如 Simon P. Stevens 提到的，慢慢地工作。获取Refactor的（免费！）副本！对于 Visual Basic，因此您将能够自动执行一些基本的重构，例如提取方法。只需将较大的代码块拆分为更小、更可测试的块，您就可以在不更改任何功能的情况下大幅提高可测试性。