модульное тестирование асинхронного кода и кода без видимых внешних эффектов

Question

На самом деле у меня есть два вопроса, хотя и немного связанных:

• Я знаю, что модульные тесты должны проверять общедоступный API.Однако, если у меня есть метод close, который закрывает сокеты и закрывает исполнителей, тем не менее, ни сокеты, ни исполнители не предоставляются пользователям этого API, должен ли я проверять, выполняется ли это, или только то, что метод выполняется без ошибок?Где находится граница между общедоступным API / поведением и подробными сведениями о impl?

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

Answer 1

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

Имея это в виду, вы можете подумать о рефакторинге своего кода, чтобы «низкоуровневая система» (например, управление сокетами и потоками) находилась вотдельный модуль, где вы явно относитесь к нему как к части контракта, который предоставляет этот модуль.