单元测试的模拟对象

本文关键字：对象 模拟 单元测试 | 更新日期: 2023-09-27 17:58:28

可能重复：
硬编码模拟对象与模拟框架

我想我终于开始理解单元测试要解决的问题了，但在实现所有细节时仍然遇到了困难。我得出的结论是，我可能需要一个"mock"（我使用这个词很轻，因为我不确定我是否需要像Moq这样的整个框架）对象来完成任务。

作为我一直在讨论的问题的一个例子，考虑Repository模式（或类似模式）的实现。正如我目前所理解的，我需要（至少）对Add()、Get()和Remove()类方法中的每一个进行测试。这很好，只是假设我想测试Add()方法如何处理null引用。在这种情况下，我是否只在测试项目中定义一个简单的类，并在适当的单元测试中将其实例设置为null？

单元测试示例（插图）：

[TestMethod]
public void TestAdd_Null()
{
    IRepository<MockObject> repository = (IRepository<MockObject>)(new Repository<MockObject>());
    MockObject testObject = null;
    repository.Add(testObject);
    Assert.IsNotNull(repository.Entity);
}
// I'm thinking I should implement something like this exclusively within the Test project.
// Is this reasonable? Or should I be looking into something else?
internal class MockObject
{
    public String Name { get; set; }
}

单元测试的模拟对象

我甚至可以说软件测试就像矩阵一样。没有人能知道什么是软件测试，你必须亲眼看看。大多数不信教的人没有给测试一个公平的机会，也从未尝试过做一些测试。欢迎来到俱乐部！

然而，测试的棘手之处在于，编写测试非常困难，有时编写可测试代码也很有挑战性。然而，今天有很多很棒的工具和技术，你应该投资成为一名更好的软件工程师。

模拟提供了你必须自己写的模拟，模拟很方便。在这种情况下，您的存储库并不是一个实际的持久性服务——在这种情况中，它只是提供了一个测试合约。如果添加null引用是不可能的，那么您应该有一个测试用例，期望这样的操作失败。我相信这是不言而喻的，但重要的是要测试这一点。

像Moq这样的库在这里可能非常有用，因为虚拟存储库什么都不做，而且您实际上希望在这里进行断言。我看不出在添加了一些东西之后，这里是如何需要属性Entity的（除了让编写测试更容易之外）。但我也认为，断言预期行为是错误的。

在某种程度上，您所做的实际上被称为集成测试，因为您不是在测试一个独立的单元，而是使用模拟工厂来测试两个组件之间的交互。这些类型的测试非常重要，但如果它们不是为了可测试而设计的，也很难处理。这就是为什么我们有依赖注入之类的东西。

你的问题并不需要具体的答案，但你走在了正确的轨道上，我希望这能在进行软件测试时给你一些洞察力和额外的信心。

相关文章：