如何将现有MVC3应用程序的开发转换为TDD方法？

Question

我有一个相当大的MVC3应用程序，其中我已经开发了一个小的第一阶段，没有编写任何单元测试，目标是特别检测重构引起的回归等问题。我知道这样说有点不负责任，但到目前为止，并没有真正需要这么做，只需进行非常简单的CRUD操作，但我希望能够继续采用TDD方法。

我已经基本完成了第一阶段，我已经写了行动和视图，其中成员可以注册为作者并创建课程模块。现在我有更复杂的阶段来实施课程的消费者和他们的受训者必须注册并完成课程，学术进展跟踪，作者反馈和财务影响。我觉得如果没有一个稳定的单元测试策略是不明智的，根据以往的经验，我认为TDD将非常适合我未来在这里的开发工作。

是否有已知的程序将开发工作“转换”为TDD，并将单元测试引入已编写的代码？我不需要幼儿园一步一步的东西，而是一般的战略指导。

顺便说一句，我已经在这个问题上包含了web开发和MVC标签，因为我相信这些开发领域可以对项目文物的单元测试需求产生重大影响。如果您不同意并希望删除其中的任何内容，请发表评论，说出原因。

Answer 1

我不知道任何现有的程序，但我可以强调我通常做什么。

对于现有系统，我的做法是先尝试编写测试以重现缺陷，然后修改代码以修复它。我说的是尝试，因为不是所有的东西都能以具有成本效益的方式重现。例如，试图编写一个测试来重现与IE3特定版本的IE浏览器相关的CSS3转换问题可能会很酷，但不能很好地利用您的时间。我通常会给自己一个写这样的测试的最后期限。唯一的例外可能是高度重视或难以手动测试的功能（如API）。

对于添加任何新功能，首先编写测试程序（好像被测类是API），验证测试失败，并实现该功能，以满足测试。重复。完成该功能后，请运行它，如PEX。它往往会突出你从未想过的事情。明白需要解决哪些问题。

对于现有的代码，我将使用代码覆盖范围来帮助我查找我没有测试过的功能。我将代码注释掉，编写测试（失败），取消注释代码，验证测试通过并重复。如果需要，我会重构代码以简化测试。 PEX也可以提供帮助。

密切关注疼痛点，因为它突出了应该重构的区域。例如，如果您的控制器直接使用ObjectContext/IDbCommand/IDbConnection进行数据访问，则可能会发现您需要配置数据库才能测试业务条件。这是我的暗示，我需要一个数据访问层的接口，所以我可以模拟它并在我的控制器中模拟这些业务条件。这同样适用于注册表访问等等。

但要明白你写的测试。 TDD的价值在某些时候会降低，编写这些测试的成本可能要比给印度某人手动测试的成本要高。