Могут ли модульные тесты иметь критерии времени выполнения?

Question

Это хорошая практика, чтобы иметь модульный тест, который определяет, сколько времени определенная функция возвращает значение. Я тестирую модульную функцию curl и хочу указать, что она должна быть отключена через 5 секунд. Это соответствует принципу работы модульных тестов?

Answer 1

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

Answer 2

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

Единственное, что меня беспокоит, это время ожидания в пять секунд, которое очень много для юнит-теста. Теперь это зависит от того, как часто это происходит. Рассматривали ли вы базовый тест (например, pinging на сервере) перед запуском curl, чтобы избежать запуска ненужного теста.

Если вы ищете альтернативы, как насчет разделения вашего теста на две части: 1 / test, как вызывается curl; 2 / проверить, что ваша функция делает с результатом? Таким образом, вы будете изолированы от сервера и вам не понадобится тайм-аут.

Answer 3

Не думаю, что это проверка контракта метода. Вот почему я бы сказал нет, это не юнит-тест. Но это звучит как какой-то системный тест.

Еще один момент, который исключает ваш пример как модульный тест, это тот факт, что для его выполнения требуется много времени (5 секунд). Как правило, вы должны иметь возможность выполнять полный набор юнит-тестов каждый раз, когда вы вносите изменения. Вы не можете долго ждать.

Вот почему я думаю, что ваш тест должен быть в другом наборе тестов, чем юнит-тесты. Это должно выполняться в ваших ежедневных сборках / непрерывной интеграции, но не перед каждой проверкой каждого программиста.

Answer 4

Что если ответ отрицательный? Значит ли это, что вы не написали бы тест?

Если это особый случай, я бы написал тест и теперь беспокоюсь об этом.

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

Answer 5

может быть, больше теста производительности, но да. у nunit они есть: http://weblogs.asp.net/egarmon/archive/2005/02/14/372114.aspx. у junitperf они есть: http://clarkware.com/software/JUnitPerf.html

Answer 6

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

Answer 7

Пуристический ответ: Да, длительный юнит-тест является запахом кода и должен быть изменен

Прагматичный ответ: Если у вас есть проблема с длительным тестом, и вы хотите, чтобы ваш набор тестов быстро провалился, добавьте время ожидания.

Answer 8

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

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