我一个人管理着一个相当大的应用程序（50k+行代码），它管理一些非常关键的业务操作。简单地描述这个程序，我会说它是一个带有从数据库中显示和更改数据能力的花哨用户界面，并且它管理着约1,000个租赁单位、约3,000名租户以及所有财务。
因为代码基础如此庞大，所以当我进行更改时，有时会在其他地方破坏某些东西。通常情况下，我通过在功能级别上检查更改的事项来测试它（即运行程序并通过用户界面操作），但我无法测试每种情况。这就是为什么我想开始使用单元测试的原因。
然而，这不是一个真正的三层程序，其中包括数据库层、业务层和用户界面层。许多业务逻辑是在用户界面类中执行的，并且许多事情都是在事件上完成的。而且，所有的操作都是由数据库驱动的，并且我还没有看到（到目前为止）有关如何对数据库交互进行单元测试的好建议。
对于这个应用程序，如何开始使用单元测试呢？要记住，我以前从未进行过单元测试或TDD。我应该重写它以删除UI类中的业务逻辑（需要大量工作）吗？还是有更好的方法？
我建议首先使用一些工具通过UI来测试应用程序。有许多工具可以用来创建测试脚本，模拟用户通过应用程序进行点击。
我还建议您在添加新功能的同时开始添加单元测试。一旦应用程序开发完成后再创建完整的覆盖范围是非常费时的，但如果您逐步地进行，那么您将分配努力。
我们通过使用专门用于单元测试的单独数据库来测试数据库交互。通过这种方式，我们有一个静态和可控的数据集，以便可以保证请求和响应。然后我们创建C#代码来模拟各种场景。我们使用nUnit来做这件事。
有一个选项是这样的--每当出现一个错误时，编写一个测试来帮助您找到错误并解决问题。确保测试在修复错误后通过。然后，一旦错误被解决，您就拥有了一个工具，可以帮助您检测未来可能影响您刚刚修复的代码块的更改。随着时间的推移，您的测试覆盖率将提高，并且您可以在进行可能产生深远影响的更改时随时运行不断增长的测试套件。
重构是更好的方法。虽然这个过程比较艰巨，但你一定要将表示层和业务逻辑分开。除非你进行了这种分离，否则你将无法对你的业务逻辑编写良好的单元测试。就是这么简单。
在重构过程中，你很可能会发现你甚至不知道存在的错误，并且最终会成为一个更好的程序员！
此外，一旦您重构了代码，您将注意到测试数据库交互变得更加容易。您将能够编写执行操作（例如“添加新租户”）的测试，该操作涉及创建一个模拟租户对象并将“他”保存到数据库中。对于下一个测试，您将编写“GetTenant”，尝试从数据库中获取刚刚创建的那个租户并将其加载到内存中...然后比较第一个和第二个租户以确保所有字段匹配值。等等。
我认为将业务逻辑与用户界面分离始终是一个好主意。其中包括更容易的单元测试和可扩展性等多个好处。你可能也想要参考基于模式的编程。这里有一个链接 http://en.wikipedia.org/wiki/Design_pattern_(computer_science) 可以帮助你了解设计模式。
现在你可以做的一件事情是，将所有业务逻辑和不同的业务基础功能隔离在你的用户界面类中，然后在每个用户界面构造函数或页面加载中进行单元测试调用以测试每个业务功能。为了提高可读性，你可以在业务功能周围应用 #region 标记。
为了长期受益，你应该学习设计模式。选择适合你项目需求的模式，并使用设计模式重新设计你的项目。
这取决于您使用的编程语言。但通常情况下，从一个简单的测试类开始，使用一些虚构的数据（但仍然是一些“真实”的数据）来测试您的代码。让它模拟应用程序中会发生的情况。如果您要更改应用程序的特定部分，请在更改代码之前编写可工作的代码。现在，由于您已经编写了代码，因此在尝试测试整个应用程序时，启动测试将是一个相当大的挑战。我建议从小处开始。但是，现在您编写代码时，请先编写单元测试，然后再编写代码。您还可以考虑重构，但我会权衡重构与边进行单元测试时逐步重写的成本。
没有比尝试单元测试更好的入门方式了 - 它不需要很长时间，而且有趣且让人上瘾。但前提是你正在处理可测试的代码。
然而，如果你试图通过一次性修复像你描述的应用程序来学习单元测试，你可能会感到沮丧和泄气 - 而且很有可能你会认为单元测试是浪费时间。
我建议下载一个单元测试框架，例如NUnit或XUnit.Net。这些框架中的大多数都有在线文档，提供简要介绍，例如NUnit Quick Start。阅读它，然后选择一个简单的、自包含的类，该类具有以下特点：
尝试编写一些测试以获得该类的良好覆盖率，然后编译和运行这些测试。
一旦掌握了这个技巧，开始寻找 重构现有代码 的机会，特别是在添加新功能或修复错误时。当这些重构导致满足上述条件的类时，请为它们编写一些测试。习惯后，可以通过编写测试来开始。
