unit-testing - 极其琐碎的方法的单元测试(是或否)

Question

假设你有一个方法:

public void Save(Entity data)
{
    this.repositoryIocInstance.EntitySave(data);
}

你会写一个单元测试吗？

public void TestSave()
{
    // arrange
    Mock<EntityRepository> repo = new Mock<EntityRepository>();
    repo.Setup(m => m.EntitySave(It.IsAny<Entity>());

    // act
    MyClass c = new MyClass(repo.Object);
    c.Save(new Entity());

    // assert
    repo.Verify(m => EntitySave(It.IsAny<Entity>()), Times.Once());
}

因为以后如果你改变方法的实现来做更“复杂”的事情，比如:

public void Save(Entity data)
{
    if (this.repositoryIocInstance.Exists(data))
    {
        this.repositoryIocInstance.Update(data);
    }
    else
    {
        this.repositoryIocInstance.Create(data);
    }
}

...您的单元测试会失败，但它可能不会破坏您的应用程序...

问题

我是否应该费心为 的方法创建单元测试？没有任何返回类型*或**不要更改内部模拟之外的任何内容 ?

Answer 1

问自己两个问题。 “这个单元测试的手动等效项是什么？”和“值得自动化吗？”。在您的情况下，它将类似于:

什么是手动等效？
- 启动调试器
- 进入“保存”方法
- 进入下一步，确保你在 IRepository.EntitySave 实现中

是否值得自动化？我的回答是“不”。从代码中可以 100% 明显看出。
从数百个类似的废物测试中，我没有看到一个有用的。