Asp.net 将单元测试慢慢集成到项目中的步骤

我目前正在与另一名合作学生合作学习一个即将完成的项目。由于这个项目是从一个合作社传到另一个合作社的，所以在这一过程中一直采取不良做法，测试一直留到最后。我决定编写单元测试，以便在测试时学习新的东西

然而，我正在开发一个3层、紧密耦合的应用程序，它似乎不可能以当前的形式进行单元测试。我不想通过一夜之间对代码进行无法识别的重构，从而甩掉另一个对这些概念一无所知的合作学生。那么，我应该采取什么步骤慢慢地将代码推向单元可测试性呢？我是否应该首先实施工厂模式，让其他学生在前进之前熟悉工厂模式

---

我道歉，如果我的知识有缺陷，不应该有任何问题。我不熟悉这一点：）

在项目中途开始新的开发实践是非常困难的。在过去，当我从事从一开始就没有经过单元测试的项目时，一个好的方法是制定“新代码必须有单元测试”的规则，但不要对为旧代码编写的单元测试施加压力

当然，当项目的结构不适合测试性时，即使这样也很困难

我最好的建议是分步进行

首先创建单元测试程序集（或项目或任何东西），其中没有测试。然后找到一小块定义和分离得相当好的代码区域，并为该区域编写一些单元测试。让你的同事也来看看，开始做一些“最佳实践”，比如每次签入任何代码时都要运行单元测试（如果可能的话，会自动进行）

一旦你有了工作，你可以慢慢地开始添加更多

钥匙慢慢地打开了。正如我所说的，从一开始就可以让旧代码免于测试。一旦您的团队掌握了单元测试的概念，并且在编写单元测试方面变得更好，您就可以稍后再讨论它。

michaelfeathers

---

很难知道实现工厂模式是否有好处，这取决于代码在做什么：）

围绕代码中的主要功能编写一系列黑盒测试如何？因为您提到它是一个ASP.NET项目，所以可以使用诸如或之类的框架来自动化web浏览器。这为您提供了一组基线功能，无论代码有多大的变化，这些功能都应该保持不变

一旦您对项目的高级功能进行了大量测试，我就会开始深入研究代码，正如Simon p.Stevens所提到的，慢慢来。获取的（免费！）副本，这样您就能够自动执行一些基本的重构，例如提取方法。只需将较大的代码块拆分为更小、更可测试的代码块，就可以在不改变任何功能的情况下大幅提高可测试性。

作者Michael Feathers（如果您有订阅，也可在Safari中获得）是执行任务的优秀资源。作者将遗留代码定义为没有单元测试的代码，并给出了大量必要的保守技术的实际演练，因为您在工作时没有安全网来测试代码。目录：

• 第一部分：变化的机制
  • 第一章。更改软件
    • 更换软件的四个原因
    • 危险的变化
  • 第二章。处理反馈
    • 什么是单元测试
    • 高级测试
    • 试验覆盖物
    • 遗留代码更改算法
  • 第三章。传感与分离
    • 伪造合作者
  • 第四章。煤层模型
    • 一大页文字
    • 接缝
    • 接缝类型
  • 第五章。工具
    • 自动重构工具
    • 模拟对象
    • 单元测试线束
    • 通用测试线束
• 第二部分：更换软件
  • 第六章。我没有太多的时间，我必须改变它
    • 萌芽法
    • 萌芽班
    • 包裹法
    • 包装类
    • 总结
  • 第七章。改变需要永远的时间
    • 理解力
    • 滞后时间
    • 打破依赖关系
    • 总结
  • 第八章。如何添加功能？
    • 测试驱动开发（TDD）
    • 差分编程
    • 总结
  • 第九章。我不能让这门课成为一个测试工具
    • 刺激性参数的情况
    • 隐藏依赖项的情况
    • 建筑集团的案例
    • 令人恼火的全球依赖
    • 可怕的情况包括依赖关系
    • 洋葱参数的情况
    • 别名参数的情况
  • 第十章。我无法在测试线束中运行此方法
    • 隐藏方法的案例
    • “有用”语言特征的案例
    • 无法检测到的副作用
  • 第十一章。我需要改变一下。我应该测试什么方法？
    • 关于效果的推理
    • 推理
    • 效应传播
    • 效果推理工具
    • 从效果分析中学习
    • 简化效果草图
  • 第十二章。我需要在一个领域做很多改变。我必须打破所有相关类的依赖关系吗？
    • 拦截点
    • 用夹点判断设计
    • 夹点陷阱
  • 第十三章。我需要做出改变，但我不知道该写什么测试 特性测试
    • 特征类
    • 目标测试
    • 写Ch的启发式方法