对大型解决方案、IOC、Moq进行单元测试改造

我正在为用VB编写的asp.net解决方案改进单元测试。Net和c#。单元测试需要验证当前的功能，并作为对未来破坏性更改的检查。

当处理没有单元测试的大型代码库时，并且在编写时没有考虑到测试，为了编写一组有用的单元测试，很有可能必须修改代码，因此您将触发您计划编写单元测试以支持的事件。这显然是有风险的，但可能不会比你每天都在做的事情更有风险。

你可以采取很多方法(很有可能这个问题会因为太宽泛而被关闭)。一种方法是创建一组良好的集成测试，以确保核心功能正常工作。这些测试的运行速度不会像单元测试那样快，但它们将进一步与遗留代码库解耦。这将给你一个很好的安全网，你需要做的任何更改作为引入单元测试的一部分。

如果您有一个合适的visual studio版本，那么您也可以在编写初始测试时使用shims(或者如果您有资金，typemock可能是一个选项)来隔离应用程序的元素。因此，例如，您可以创建数据库的shims，以将其余代码与数据库隔离。

第一个问题，要正确地进行单元测试，我应该设置一个测试项目并从中运行所有测试，还是应该为每个项目设置一个测试项目以仅测试该dll的功能?

就我个人而言，我更喜欢将每个程序集视为一个可测试的单元，因此我倾向于为每个包含生产代码的程序集创建至少一个测试项目。这是否有意义，虽然，取决于什么是包含在每个程序集…我也倾向于至少有一个测试项目用于顶级项目的集成测试。

第二个问题，我是否需要实现IOC才能使用MOQ?

简短的答案是否定的，但这取决于你的类做什么。如果您想使用Moq进行测试，那么如果您的类支持依赖注入，那么当然更容易这样做，尽管您不需要使用IOC容器来实现这一点。通过下面的构造函数或通过属性进行手工注入，可以形成一个桥，允许注入测试存根。

public SomeConstructor(ISomeDependency someDependency = null) {
    if(null == someDependency) {
        someDependency = new SomeDependency();
    }
    _someDependency = someDependency;
}

第三个问题，是否有可能将IOC重构成这样一个巨大的解决方案?

是的，有可能。更重要的问题是，这值得吗?你似乎在建议用大爆炸的方法来解决移民问题。如果你的开发团队在这方面没有太多经验，那么这似乎是非常冒险的。更安全的方法可能是针对应用程序的特定区域并迁移该部分。如果您的程序集是离散的，那么它们应该在您的应用程序中形成相当容易的分割点。了解什么是有效的，什么是无效的，以及你感受到的好处和意想不到的痛苦。使用它来决定如何以及何时迁移其余的代码。

第四个问题，还有什么其他办法可以尽快完成这项工作?

正如我上面所说的，我不确定尽快是正确的方法。单元测试的工作可以作为缓慢的迁移来完成，在由于业务需求而实际更改代码时添加测试。这有助于确保测试人员也被分配来捕获您作为重构的一部分引入的任何错误，这些错误可能需要发生以支持测试。