Не понимаю цель поведенческих тестов

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);
    }

}

Теперь нам нужно написать немало тестов, и я думаю, что значение становится более очевидным. Особенно, когда мы пишем тест с параметром Y, равным нулю.