Разработка надежного модульного теста - тестирование одной и той же логики несколькими различными способами?

Question

В модульном тестировании очень просто попасть в ловушку, просто вызвав логику реализации.

Например, если тестируется массив целых чисел, все из которых должны быть на два больше, чем другие (2, 4, 6, 8 и т. Д.), Действительно ли достаточно получить возвращаемое значение из метода и утверждать, что этот шаблон это тот случай?

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

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

Спасибо

Answer 1

Ваши юнит-тесты должны проверить все ваши предположения.Делаете ли вы это в 1 или в нескольких тестах, это личное предпочтение.

В приведенном выше примере у вас было два разных допущения: (1) Каждое значение должно увеличиваться на 2. (2) Все значения должныбыть четным.

Должен ли (-8, -6, -4, -2) пройти / потерпеть неудачу?

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

Answer 2

Я бы порекомендовал несколько тестов.Если вам когда-нибудь понадобится изменить поведение, вам нужно иметь как можно меньше тестов.Это также облегчает поиск проблемы.Если вы действительно взорвете реализацию и получите [1,3,4,5], ваш один тест провалится, но вы получите только один сбой за первое, что вы протестируете, когда на самом деле есть две разные проблемы.

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

testEntriesStepByTwo

testEntriesAllEven

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

Answer 3

Например, если тестируется массив целые, которые должны быть все два выше чем другой (2, 4, 6, 8 и т. д.), является это действительно достаточно, чтобы получить возврат значение из метода и утверждают, что это шаблон дела?

Возможно, вам нужно немного подумать о том, как будет использоваться эта функция. Это будет использоваться с очень большими числами? Если это так, вы можете попробовать некоторые тесты с очень большими числами. Будет ли он использоваться с отрицательными числами?

Я что-то упустил? Кажется как метод единого модульного тестирования чтобы быть более устойчивым путем тестирования То же самое ожидание в нескольких отношениях. Так вышеуказанное ожидание может быть подтверждено проверяя увеличение двух происходит, но и следующий номер делится на 2. Или это просто избыточная логика «избыточная логика»

Хм ... ну 1,3,5,9 пройдет тест assertEachValueIncrementsByTwo, но не пройдет тест assertValuesDivisibleByTwo. Имеет ли значение, что они делятся на 2? Если так, то вам действительно стоит это проверить. Если нет, то это бессмысленный избыточный тест.

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

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

Answer 4

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

Answer 5

Если вы утверждаете, что ваш массив содержит 2,4,6,8 - тогда ваша логика тестирования может быть ошибочной, потому что ваш тест прошел бы, если бы вы только что вернули массив с этими элементами, но не с, скажем, 6,8 , 10,12. Вы должны проверить, что расчет правильный. Поэтому вам нужно протестировать его с несколькими массивами, в данном конкретном случае.

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