Функциональные тесты TDD - PullRequest
1 голос
/ 13 октября 2011

Должен ли я написать модульный тест для всех вложенных методов или достаточно написать один тест для вызывающего?

Например:

void Main()
{
    var x = new A().AFoo();
}

public class A
{
    public int AFoo()
    {        
        // some logic
        var x = new B().BFoo();

        // might have some logic

        return x;
    }
}

public class B
{
    public int BFoo()
    {
        // some logic
        return ???;
    }
}

Этого достаточно для написания модульного теста для метода Main () или мне нужно написать тесты для методов Main, A.AFoo (), B.BFoo ()? Как глубоко я должен идти?

Заранее спасибо.

Ответы [ 3 ]

5 голосов
/ 13 октября 2011

Пурист-тестировщик скажет, что вам нужно создать модульные тесты для классов A и B.

В каждом классе должны быть протестированы все методы.Если метод может делать больше, чем одно (например, если у вас есть оператор if), то у вас должен быть тест для каждого пути.Если тесты становятся слишком сложными, то, вероятно, будет хорошей идеей реорганизовать код, чтобы упростить тесты.

Обратите внимание, что в его нынешнем виде сложно тестировать A изолированно, поскольку оно зависит от B.Если B просто, как сейчас, вероятно, все в порядке.Возможно, вы захотите назвать свои тесты для интеграционных тестов A, потому что технически они тестируют вместе и A, и B.Другой вариант заключается в том, чтобы метод AFoo принимал в качестве параметра экземпляр B, с которым он работает.Таким образом, вы можете смоделировать экземпляр B и провести настоящий модульный тест.

2 голосов
/ 13 октября 2011

Юнит-тесты должны работать на юнитах, в случае ООП юнитами являются классы и методы классов. Это означает, что вы должны написать отдельный тестовый класс для каждого рассматриваемого класса и по крайней мере один метод тестирования для каждого метода, представленного в классе. Более того, важно максимально изолировать классы, чтобы ошибка в классе B не вызывала сбоев в классе A. Вот почему инверсия управления (Dependency Injection) так полезна, потому что если вы можете внедрить экземпляр класса B в экземпляр класса A, вы можете изменить B на просто объект Mock.

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

Я бы порекомендовал прочитать некоторые материалы в Интернете, объясняющие разработку через тестирование и как имитировать объекты, и, возможно, использовать некоторые из существующих превосходных библиотек насмешек, таких как JMock . См. вопрос для получения дополнительных ссылок.

1 голос
/ 13 октября 2011

Модульные тесты должны помочь вам сократить усилия по отладке.Поэтому, когда вы просто пишете модульные тесты для AFoo и ни один для BFoo, и один из ваших тестов не проходит, вы, вероятно, не будете знать, является ли проблема частью класса A или класса B. Написание тестов также для BFooпоможет вам выделить ошибку за меньшее время.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...