改造单元测试以适应大型解决方案，IOC，最小起订量 [英] Retrofit unit tests to large solution, IOC, Moq

问题描述

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

I am in the process of retrofitting unit tests for a asp.net solution written in VB.Net and c#. The unit tests need to verify the current functionality and act as a check for future breaking changes.

该解决方案包括:

1个MVC Web项目 用vb.net编写(不要问，这是一件很古老的事情)

1 MVC web project written in vb.net (don't ask, it's a legacy thing)

10个其他支持项目，每个项目均包含逻辑分组的功能 用C#编写，每个项目都包含存储库和DAL

10 other supporting projects each containing logically grouped functionality written in C#, each project contains repositories and DAL

由于尚未在任何地方实现控制反转(IOC)，因此所有类都紧密耦合.

All the classes are tightly coupled as there is no inversion of control (IOC) implemented anywhere, yet.

当前要测试控制器，有以下堆栈:

currently to test a controller there is the following stack:

• 控制器
• • 存储库
  • controller
  • • repository
    • • dal
      • • dal
        • • • 记录
            • • • logging

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

                First question, to unit test this correctly would I setup 1 test project and run all tests from it, or should I setup 1 test project for each project to test the functionality of that DLL only?

                第二个问题，我是否需要实施IOC才能使用最小起订量?

                Second question, do I need to implement IOC to be able to use MOQ?

                第三个问题，是否有可能将IOC重构为如此庞大的解决方案?

                Third question, is it even possible to refactor IOC into a huge solution like this?

                第四个问题，还有哪些其他选项可以尽快完成此任务?

                Forth question, what other options are available to get this done asap?

                推荐答案

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

                I am in the process of retrofitting unit tests for a asp.net solution written in VB.Net and c#. The unit tests need to verify the current functionality and act as a check for future breaking changes.

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

                When working with a large code base that doesn't have unit tests and hasn't been written with testing in mind, there is a good chance that in order to write a useful set of unit tests you will have to modify the code, hence you're going to be triggering the event that you're planning on writing the unit tests to support. This is obviously risky, but may not be any riskier than what you're already doing on a day to day basis.

                您可以采用多种方法(这个问题很可能会因为过于广泛而封闭).一种方法是创建一组良好的集成测试，以确保核心功能正常运行.这些测试的运行速度不会像单元测试那样快，但是它们将与传统代码库进一步分离.这将为您在引入单元测试过程中需要进行的任何更改提供一个良好的安全网.

                There are a number of approaches that you could take (and there's a good chance that this question will be closed as too broad). One approach is to create a good set of integration tests ensure that the core functionality is working. These tests won't be as fast to run as unit tests, but they will be further decoupled from the legacy code base. This will give you a good safety net for any changes that you need to make as part of introducing unit testing.

                如果您拥有适当版本的Visual Studio，则还可以使用垫片 a>(或者，如果您有资金，可以选择typemock)在编写初始测试时隔离应用程序的元素.因此，例如，您可以为dal创建垫片，以将其余代码与数据库隔离.

                If you have an appropriate version of visual studio, then you may also be able to use shims (or if you have funds, typemock may be an option) to isolate elements of your application when writing your initial tests. So, you could for example create shims of your dal to isolate the rest of your code from the db.

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

                First question, to unit test this correctly would i setup 1 test project and run all tests from it, or should i setup 1 test project for each project to test the functionality of that dll only?

                我个人比较喜欢将每个程序集都视为可测试的单元，因此我倾向于为每个包含生产代码的程序集至少创建一个测试项目.不过，这是否有意义，多少取决于每个程序集中包含的内容……我也倾向于至少有一个测试项目来进行顶层项目的集成测试.

                Personally, I prefer think of each assembly as a testable unit, so I tend to create at least one test project for each assembly containing production code. Whether or not that makes sense though, depends a bit on what's contained in each of the assemblies... I'd also tend to have at least one test project for integration tests of the top level project.

                第二个问题，我是否需要实施IOC才能使用最小起订量?

                Second question, do i need to implement IOC to be able to use MOQ?

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

                The short answer is no, but it depends what your classes do. If you want to test using Moq, then it's certainly easier to do so if your classes support dependency injection, although you don't need to use an IOC container to achieve this. Hand rolled injection either through constructors like below, or through properties can form a bridge to allow testing stubs to be injected.

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

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

                Third question, is it even possible refactor IOC into a huge solution like this?

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

                Yes it's possible. The bigger question is it worth it? You appear to be suggesting a big bang approach to the migration. If you have a team of developers that don't have much experience in this area, this seems awfully risky. A safer approach might be to target a specific area of the application and migrate that section. If your assemblies are discrete then they should form fairly easy split points in your application. Learn what works and what doesn't, along with what benefits and unexpected pain you're feeling. Use that to inform your decision about how and when to migrate the rest of the code.

                第四个问题，还有哪些其他选项可以尽快完成此任务?

                Forth question, what other options are available to get this done asap?

                如上所述，我不确定ASAP确实是正确的方法.进行单元测试的工作可以通过缓慢的迁移来完成，可以在由于业务需求而实际更改代码时添加测试.这有助于确保还分配了测试人员来捕获您在重构过程中引入的任何错误，以支持测试.

                As I've said above, I'm not sure that ASAP is really the right approach to take. Working towards unit-testing can be done as a slow migration, adding tests as you actually change the code due to business requirements. This helps to ensure that testers are also allocated to catch any errors that you introduce as part of the refactoring that might need to take place to support the testing.

                这篇关于改造单元测试以适应大型解决方案，IOC，最小起订量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！