Сколько я должен изолировать мой метод для модульного тестирования? - PullRequest
Новая
       18

Сколько я должен изолировать мой метод для модульного тестирования?

0 голосов
/ 11 июля 2019

У меня есть следующий метод: 

public < V extends U > boolean matchesObject (V object, String filter) {

    if (filterIsAny(filter)) return true;

    else {

        List<T> targets = getFilterTarget(object);

        for (T t : targets) if (matches(t, filter)) return true;
        return false;

    }

}

, где filterIsAny (фильтр) - тривиальный метод (просто проверяет фильтр! = Ноль).

Мой вопрос таков: когда я выполняю модульное тестирование, стоит ли издеваться над этим методом, чтобы я был уверен, что моя функция следует по правильному пути в функции, или я просто предполагаю, что мой filterIsAny (фильтр) работает и тестировать реальным методом?В этом конкретном случае довольно легко смоделировать этот метод, но у меня есть другие случаи, когда потребовалось бы несколько строк кода, чтобы смоделировать промежуточные результаты, возвращаемые тривиальными функциями, такими как list.indexOf (object) в списке ложных объектов.

Я знаю, что это не будет "чистое" модульное тестирование, поскольку теоретически я буду тестировать более одной функции за раз, но как стоит проводить чистое модульное тестирование, когда для этого требуется больше работы, чемнайти ошибку в коде в случае провала теста?

1 Ответ

1 голос
/ 11 июля 2019

Предположим, что filterIsAny работает до тех пор, пока не получит нетривиальную логику.

Если ваша функция является оболочкой для одного чистого оператора Java, который не имеет логических ветвей, вы можете безопаснопропустите написание модульного теста для него и, следовательно, только его в других модульных тестах.То, что вы делаете хотите проверить, - это различные ветви в тестируемом методе, при условии, что он имеет нетривиальную логику.

Здесь вы должны настроить объект фильтра так, чтобы он генерировалtrue и false результат при тестировании matchesObject(V object, String filter) на основе тестируемой логической ветви (нет совпадений в коллекции, одно совпадение в коллекции, недопустимый тип коллекции (если возможно), нулевой ввод и т. Д.)

В вашем случае вы можете пропустить оценку filterIsAny(filter) до истинной ветви, поскольку впоследствии вы выполняете тривиальный оператор return true.

Кстати, рассмотрите возможность рефакторинга на Stream.anyMatch(), если это возможно;это уменьшит количество операторов возврата в вашей функции и улучшит читабельность.

...