我正在改进用VB.Net和c＃编写的asp.net解决方案的单元测试。 单元测试需要验证当前的功能，并检查未来的重大变化。
解决方案包括：
1个MVC网络项目 写在vb.net（不要问，这是遗产）
其他10个支持项目，每个项目都包含逻辑分组功能 用C＃编写，每个项目都包含存储库和DAL
所有类都是紧密耦合的，因为在任何地方都没有实现控制反转（IOC）。
目前要测试一个控制器，有以下堆栈：
第一个问题，要正确地进行单元测试，我会设置1个测试项目并从中运行所有测试，还是应该为每个项目设置1个测试项目来测试该DLL的功能？
第二个问题，我是否需要实施IOC才能使用MOQ？
第三个问题，是否有可能将IOC重构为这样一个巨大的解决方案？
第四个问题，有什么其他选择可以尽快完成这项工作？
答案 0 :(得分：6)
我正在改进用VB.Net和c＃编写的asp.net解决方案的单元测试。单元测试需要验证当前的功能，并检查未来的重大变化。
当使用没有单元测试的大型代码库并且没有考虑到测试时，很有可能为了编写一组有用的单元测试，你将会必须修改代码，因此您将触发您计划编写单元测试以支持的事件。这显然是有风险的，但可能不会比你日常做的那样冒险。
您可以采取多种方法（这个问题很有可能会因为过于宽泛而被关闭）。一种方法是创建一组良好的集成测试，以确保核心功能正常运行。这些测试不像单元测试那样快速运行，但它们将与遗留代码库进一步分离。这将为您在引入单元测试时需要进行的任何更改提供良好的安全网。
如果您有适当版本的visual studio，那么您也可以使用shims（或者，如果您有资金，可以选择输入样式），以便在编写初始测试时隔离应用程序的元素。因此，您可以创建dal的填充程序，以将其余代码与db隔离开来。
第一个问题，为了正确地进行单元测试，我会设置1个测试项目并从中运行所有测试，或者我应该为每个项目设置1个测试项目来测试该DLL的功能吗？
就个人而言，我更喜欢将每个程序集视为可测试单元，因此我倾向于为包含生产代码的每个程序集创建至少一个测试项目。这是否有意义，取决于每个程序集中包含的内容......我还倾向于至少有一个测试项目用于顶级项目的集成测试。 / p>
第二个问题，我是否需要实现IOC才能使用MOQ？
简短的回答是否定的，但这取决于你的课程。如果你想使用Moq进行测试，那么如果你的类支持依赖注入，它肯定更容易实现，尽管你不需要使用IOC容器来实现这一点。通过下面的构造函数手动注射，或通过属性形成一个桥梁，以允许测试存根被注入。
public SomeConstructor(ISomeDependency someDependency = null) {
if(null == someDependency) {
someDependency = new SomeDependency();
}
_someDependency = someDependency;
}
第三个问题，是否有可能将IOC重构成这样一个巨大的解决方案？
是的，这是可能的。更大的问题是值得吗？您似乎建议采用大爆炸方式进行迁移。如果你有一个在这个领域没有多少经验的开发团队，这看起来非常危险。更安全的方法可能是针对应用程序的特定区域并迁移该部分。如果您的程序集是离散的，那么它们应该在您的应用程序中形成相当简单了解哪些有效，哪些无效，以及您感受到的益处和意外疼痛。使用它来告知您关于如何以及何时迁移其余代码的决定。
第四个问题，有什么其他选择可以尽快完成这项工作？
正如我上面所说，我不确定ASAP是否真的是正确的方法。可以通过缓慢迁移来完成单元测试，在实际根据业务需求更改代码时添加测试。这有助于确保测试人员也被分配以捕获您作为重构的一部分引入的任何错误，这些错误可能需要用于支持测试。