Question

我希望有人可以帮助我看到这些测试中的真正价值，因为我阅读了很多关于它们的内容，甚至在最近的项目中与他们合作。但我从未真正看到测试中的真正价值。当然，我可以理解为什么写它们，看看它们是如何有用的。但似乎这些类型的测试几乎没有投资回报率。以下是代码库中某个类的示例：

class ServiceObject : IServiceObject
{
    Dependency _dependency;

    ServiceObject(Dependency dependency)
    {
        this._dependency = dependency
    }

    bool SomeMethod()
    {
        dependency.SomePublicMethod();
    }
}

然后在我们的行为测试中，我们会像这样编写测试（伪代码）：

void ServiceObject_SomeMethod_Uses_Dependency_SomePublicMethod()
{
    create mock of IServiceObject;
    stub out dependency object
    add expectation of call to dependency.SomePublicMethod for IServiceObject.SomeMethod

    call mockserviceobject.SomeMethod

    check whether expectation was satisfied
}

显然缺少一些细节但是如果你熟悉这种类型的测试，你就会明白。

所以我的问题实际上源于这样一个事实：我无法看到知道我的ServiceObject调用依赖方法是多么有价值。我理解它背后的原因是因为你想确保方法的逻辑正在击中它应该的部分。但我看不出这是一种可持续的测试模式？

我编写了逻辑并知道代码应该如何工作，为什么在我测试一次以确保代码工作后它会改变？现在您可以说，如果您在团队环境中工作，您可能希望确保某人不会出现并更改代码，以便意外跳过依赖关系，从而确保他们了解它。但是如果因为有正当理由而跳过该怎么办呢。然后，整个测试，也许任何其他测试都将被废弃。

无论如何，我只是希望有人能够开启这些类型测试的真正潜力。

Answer 1

目标是孤立地测试类，真正对其进行单元测试。确认它完全履行其职责。

在这种情况下，代码相当简单。当处理路径中存在条件性，将参数传递给依赖项并对依赖项的结果执行处理时，此类测试的值可能会变得更加清晰。

例如，假设方法是这样的：

bool someMethod(int paramX, int param Y ){

    if ( (paramX / paramY) > 5 ){
         return dependency.doOneThing(paramX);
    } else {
         return dependency.doSomethingElse(paramY);
    }

}

现在我们要编写很多测试，我认为价值变得更加明显。特别是当我们编写一个paramY设置为零的测试时。

不了解行为测试的目的

1 个答案: