什么是单元测试嘲讽的依赖关系的好处是什么? [英] What is the benefits of mocking the dependencies in unit testing?

查看:119
本文介绍了什么是单元测试嘲讽的依赖关系的好处是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的工作单元测试的东西为我的控制层和业务层(C#,MVC)。而我使用起订量DLL在单元测试嘲讽真正的/依赖的对象。

I am working on unit testing stuffs for my controller and service layers(C#,MVC). And I am using Moq dll for mocking the real/dependency objects in unit testing.

不过我对于嘲笑的依赖或实物有点混淆。让我们在下面的单元测试方法的例子: -

But I am little bit confuse regarding mocking the dependencies or real objects. Lets take a example of below unit test method :-

[TestMethod]
public void ShouldReturnDtosWhenCustomersFound_GetCustomers ()
{
    // Arrrange 
    var name = "ricky";
    var description = "this is the test";

    // setup mocked dal to return list of customers
    // when name and description passed to GetCustomers method
    _customerDalMock.Setup(d => d.GetCustomers(name, description)).Returns(_customerList);

    // Act
    List<CustomerDto> actual = _CustomerService.GetCustomers(name, description);

    // Assert
    Assert.IsNotNull(actual);
    Assert.IsTrue(actual.Any());

    // verify all setups of mocked dal were called by service
    _customerDalMock.VerifyAll();
}

在上面的单元测试方法,我嘲讽GetCustomers的方法,并返回一个客户名单。其中已定义。看起来像如下:

In the above unit test method I am mocking the GetCustomers method and returning a customer list. Which is already defined. And looks like below:

List<Customer> _customerList = new List<Customer>
{
    new Customer { CustomerID = 1, Name="Mariya",Description="description"},
    new Customer { CustomerID = 2, Name="Soniya",Description="des"},
    new Customer { CustomerID = 3, Name="Bill",Description="my desc"},
    new Customer { CustomerID = 4, Name="jay",Description="test"},
};

和允许对客户嘲笑的对象和实际对象断言的断言一看: -

And lets have a look on the Assertion of Customer mocked object and actual object Assertion :-

Assert.AreEqual(_customer.CustomerID, actual.CustomerID);
Assert.AreEqual(_customer.Name, actual.Name);
Assert.AreEqual(_customer.Description, actual.Description);



但在这里我不理解这(上述单元测试)总是很好地工作。意味着我们只是测试(在断言),我们通过或我们正在返回(以嘲讽的对象)。而我们知道,真正/实际的对象总是会返回我们通过哪些列表或对象。

But here I am not understanding that it(above unit test) always work fine. Means we are just testing(in Assertion) which we passed or which we are returning(in mocking object). And we know that the real/actual object will always return which list or object that we passed.

那么,什么是做单元测试或在此嘲讽的意思吗?

So what is the meaning of doing unit testing or mocking here?

推荐答案

嘲讽的真正目的是要实现真正的隔离。

The true purpose of mocking is to achieve true isolation.

说你有一个的CustomerService 类,即依赖于 CustomerRepository 。你写几个单元测试覆盖由的CustomerService 提供的功能。他们全部通过。

Say you have a CustomerService class, that depends on a CustomerRepository. You write a few unit tests covering the features provided by CustomerService. They all pass.

一个月后,一些进行了更改,突然你的 CustomerServices 单元测试启动失败 - 你需要找到问题的所在。

A month later, a few changes were made, and suddenly your CustomerServices unit tests start failing - and you need to find where the problem is.

所以,你认为:

由于测试一个单元测试 CustomerServices 失败,这个问题必须在该类!!

Because a unit test that tests CustomerServices is failing, the problem must be in that class!!

右键?错误!这个问题可能是无论是在 CustomerServices 或任何其depencies的,即 CustomerRepository 。如果任其依赖的失败,很可能是被测试的类将失败过

Right? Wrong! The problem could be either in CustomerServices or in any of its depencies, i.e., CustomerRepository. If any of its dependencies fail, chances are the class under test will fail too.

现在想象一个巨大的依赖关系链: A 取决于 B B 取决于 C ... >取决于以Z 以Z 推出的所有的单元测试将会失败。

Now picture a huge chain of dependencies: A depends on B, B depends on C, ... Y depends on Z. If a fault is introduced in Z, all your unit tests will fail.

这就是为什么你需要该类隔离下的它的相关性测试(可能它是一个域对象,一个数据库连接,文件资源等)。你要测试的单位

And that's why you need to isolate the class under test from its dependencies (may it be a domain object, a database connection, file resources, etc). You want to test a unit.

这篇关于什么是单元测试嘲讽的依赖关系的好处是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆