Нужно ли писать модульные тесты для методов служб без логики?

Question

Нужны ли такие методы тестирования?

@Transactional
@Override
public Charge saveAndFlush(Charge charge) {
    return chargesRepository.saveAndFlush(charge);
}

В принципе тестировать нечего.Поэтому возник вопрос - написать тест в любом случае, потому что в будущем, возможно, кто-то добавит сюда логику.Или пусть он напишет того, кто будет добавлять логику (если вообще).

Answer 1

почему вы вообще пишете тесты?чтобы облегчить жизнь.не будь фанатиком, будь прагматичным.

какова будет стоимость?

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

каково будет значение?

• проверка, делегирует ли метод A непосредственно B?в таком случае, может быть, вам вообще не нужна A
• проверка, находится ли транзакция в ожидании или операции db верны?вам понадобятся интеграционные тесты для этой
• проверки, если в методе больше ничего не делается?для этого вам понадобятся мутационные тесты

, поэтому в этом тесте действительно трудно увидеть реальную ценность.дополнительно: ожидаете ли вы, что этот код будет часто меняться?будет ли это действительно плохо, если он потерпит неудачу (10 минут фиксирования / звонка ночью / 1 млн. долл. США / крушения самолета)?если ответы «нет», то стоимость намного больше, чем значение

, но ...

• , если этот метод широко используется вваше приложение и другие разработчики часто по недоразумению удалить @Transactional?добавить тест!проверить с помощью отражения, если аннотация присутствует

• , если это очень важный метод?сделать мутационное тестирование, проверить, выполнено ли делегирование, проверить, не изменился ли параметр

• , если вы ожидаете, что этот метод будет часто меняться и вызывать много проблем?добавить тест, который проверяет, сохраняются ли основные свойства (транзакционные и делегирование)

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

Answer 2

Лично я бы пока пропустил написание теста для этого метода обслуживания.В любом случае вам нужно будет написать тесты для вашей части MVC.Проверка того, что конечная точка:

• Возвращает JSON / XML / что угодно
• Принимает и анализирует HTTP-параметры
• Не обращается к ленивым полям
• Распространяетсялогика к нужному сервису и инициирует сеансы и транзакции ORM

Конечная точка вызовет этот сервис и неявно проверит его.

Позже, когда вы добавите больше логики в этот сервис - вы также можете добавить тесты сервисного уровня (написание многих тестов MVC сложнее и медленнее).Я бы не стал писать такие тесты как unit (см. Статьи ниже).

PS, где я могу прочитать о том, что именно и как тестировать?... Я до сих пор не нашел практических примеров того, как тестировать и что труднее тестировать, чем hello world

Надеюсь, это поможет:

• Построение тестовой пирамиды для оптимизации автоматизированного тестирования
• Анемичная архитектура - враг тестирования

Answer 3

Основной причиной существования этого метода является аннотация транзакции и побочный эффект в хранилище сборов.Это также наиболее вероятная / единственная вещь, которая не будет работать, как ожидалось.Это то, что вы узнали с помощью интеграционного теста.Модульное тестирование совершенно бессмысленно, потому что вы будете издеваться над хранилищем и игнорировать аннотации.Итак, вы в основном юнит-тестирование, что случайный вызов на макете работает.Что, как ни удивительно, в основном работает так, как вы надеетесь.

Итак, убедитесь, что вы охватили все соответствующие методы хранилища всего несколькими хорошими тестами интеграции / сценариев (т.е. не пишите по одному на метод, а объединяйтеих в реалистичные сценарии).Фокусируйте модульные тесты на вещах с алгоритмической сложностью, которые имеют более 1 строки кода или любой вид ветвей.Таким образом, вы можете высмеивать ваш класс DAO, когда модульное тестирование классов обслуживания с использованием реальной бизнес-логики может иметь реальные ошибки, поскольку вы уже знаете, что DAO имеют желаемые побочные эффекты от интеграционного тестирования.

Answer 4

проверять нечего

Ну, есть.Поскольку выполнение без тестов не может различить правильную реализацию и следующие ошибочные «реализации»:

{
   return null;
}

{
   return chargesRepository.saveAndFlush(null);
}

{
   return chargesRepository.saveAndFlush(new Charge());
}

{
   return chargesRepository.someOtherMethod(charge);
}

Но вы правы, считая, что очень мало для тестирования.Предполагая, что класс chargesRepository уже должным образом протестирован, вам нужно только один или два модульных теста, чтобы показать, что метод правильно делегирует chargesRepository.

Answer 5

Я нашел ответ на похожий вопрос:

Правило большого пальца Кента Бека:

Проверьте все, что может сломаться.Конечно, это в некоторой степени субъективно.Для меня тривиальные геттеры / сеттеры и однострочные, как у вас выше, обычно не стоят того.Но опять же, я трачу большую часть своего времени на написание модульных тестов для унаследованного кода, мечтая только о хорошем новом проекте TDD ... В таких проектах правила разные.При использовании унаследованного кода основная цель - охватить как можно больше усилий с минимальными усилиями, поэтому модульные тесты, как правило, более высокого уровня и более сложные, больше похожи на интеграционные тесты, если кто-то педантичен в отношении терминологии.И когда вы боретесь за то, чтобы увеличить общее покрытие кода с 0%, или просто сумели поднять его более чем на 25%, методы получения и установки модульного тестирования - это наименьшее из ваших беспокойств.

OTOH в проекте TDD с нуля,может быть более логично писать тесты даже для таких методов.Тем более, что вы уже написали тест до того, как у вас появится возможность задуматься: «Стоит ли эта строка для отдельного теста?».По крайней мере, эти тесты тривиальны для написания и быстрого запуска, так что в любом случае это не имеет большого значения.

Answer 6

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