В примерах книги Кента Бекка про TDD он пишет простые юнит-тесты, где обычно корректность работы к.-то функциональности проверяется на каком-то одном экземпляре входных данных. А вообще, в тестах своих вы как поступаете?
Я вот до сих пор, вместо того, чтобы писать:

assertTrue(Number.isNatural(2));

писал что-то вроде:

for (int i = 1; i <= MAX; ++i) {
    assertTrue(Number.isNatural(i));
}

Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Здравствуйте, kurel, Вы писали:

K>писал что-то вроде:
K>

K>for (int i = 1; i <= MAX; ++i) {
K>    assertTrue(Number.isNatural(i));
K>}
K>

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Как минимум, усложняется локализация ошибки (точнее, значения данных) в случае непрохождения теста. В таких случаях я добавлял (пользуюсь NUnit) в вызов Assert текущее значение тестовых данных.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.


Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

Как уже объяснил коллега andrey82, вариант с циклом плох.
Для подобных тестов есть специальные инструменты — теории в JUnit/NUnit, а в TestNG похожий синтаксис имеют параметризованные тесты.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

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

Если надо проверить корректность вычисления функции, при условии, что в некоем диапазоне должен быть один результат, а вне его — другой, я обычно делают несколько единичный проверок: точка внутри диапазона, точки на границах диапазона, точка(или пара точек) вне диапазона. При этом очень помогают параметризованные тесты в NUnit.

Здравствуйте, Sshur, Вы писали:

S>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

Блин, а я дурак до сих пор тестировал свой код, как черный ящик. Только вот посмотрев, какие тесты пишет Кент Бек к своему коду, начал догадываться, что что-то не так.

Здравствуйте, kurel, Вы писали:

K>Здравствуйте, Sshur, Вы писали:

S>>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

K>Блин, а я дурак до сих пор тестировал свой код, как черный ящик. Только вот посмотрев, какие тесты пишет Кент Бек к своему коду, начал догадываться, что что-то не так.

Это ирония была? Каждый волен писать как он хочет

Как по мне, так юнит тесты подразумевают проверку срабатывания заложенных сценариев. Если неизвестно, какие сценарии предполагаются, то это уже не юнит тесты

Здравствуйте, Sshur, Вы писали:

S>Это ирония была?

нет

Здравствуйте, kurel, Вы писали:

K>Здравствуйте, Sshur, Вы писали:

S>>Это ирония была?

K>нет

ну и хорошо

Еще вопрос. Немного связанный с предыдущим.
Какой из тестов "лучше"?

tree = BinaryTree()
tree.add(5)
assertEquals(tree.getRoot(), Node(5))
assertIsNone(tree.getRoot().leftChild())
assertIsNone(tree.getRoot().rightChild())

или

tree = BinaryTree()
for n in range(0, 2):
    tree.add(5)
    assertEquals(tree.getRoot(), Node(5))
    assertIsNone(tree.getRoot().leftChild())
    assertIsNone(tree.getRoot().rightChild())

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

Или вы бы написали только первый тест?

Здравствуйте, kurel, Вы писали:


K>Откуда возник второй такой дебильный тест?
K>Там проверяется, что происходит, если в дерево с одним узлом добавить значение, равное значению в единственном узле (это проверяется во втором цикле).

K>Или вы бы написали только первый тест?

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

Здравствуйте, Sshur, Вы писали:


S>Если подразумевается, что добавление второй такой же ноды должно игнорироваться, то второй шаг цикла это отдельный сценарий и его тоже надо тестировать

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

Здравствуйте, kurel, Вы писали:

K>Или вы бы написали только первый тест?
Тесты разное проверяют. Кто из них лучше -- хз.
Добавь коментарии -- сразу же станет понятнее.

K>Откуда возник второй такой дебильный тест?
K>Там проверяется, что происходит, если в дерево с одним узлом добавить значение, равное значению в единственном узле (это проверяется во втором цикле).
Первый тест это не проверяет. Если его изменить, чтобы проверял, то он будет лучше. В данном случае, любой тест без цикла лучше теста с циклом.

СУВ, Aikin

Здравствуйте, Sshur, Вы писали:

S>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма.

т.е. для рефакторинга такие тесты не помогают?
немного поменял код, и тесты уже не полные?

Здравствуйте, Abyx, Вы писали:


A>т.е. для рефакторинга такие тесты не помогают?
A>немного поменял код, и тесты уже не полные?

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

Здравствуйте, Sshur, Вы писали:

A>>т.е. для рефакторинга такие тесты не помогают?
A>>немного поменял код, и тесты уже не полные?

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

я и не говорил про функционал. добавление/удаление ветвей не обязательно меняет функционал

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, Sshur, Вы писали:

A>>>т.е. для рефакторинга такие тесты не помогают?
A>>>немного поменял код, и тесты уже не полные?

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

A>я и не говорил про функционал. добавление/удаление ветвей не обязательно меняет функционал

Тогда все старые тесты должны ходить, естественно.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Для специальных случаев (0, 1, 2) делаются отдельные тесты.
Остальные случаи проверяются циклом еще в одном тесте.

B>Остальные случаи проверяются циклом еще в одном тесте.

За такое надо бить по рукам и заставлять читать книжки про юнит-тесты в частности и теории тестирования вообще.

Здравствуйте, abibok, Вы писали:

B>>Остальные случаи проверяются циклом еще в одном тесте.
A>За такое надо бить по рукам и заставлять читать книжки про юнит-тесты в частности и теории тестирования вообще.

Окей. Как вы тогда напишете тесты для генератора простых чисел?

B>Окей. Как вы тогда напишете тесты для генератора простых чисел?

Что еще известно про этот генератор? Если ничего и на выходе рандом, то:
1) получить одно число и проверить его на простоту и знак (больше нуля).
2) если числа выдаются по порядку, то проверить, что первый результат = 2, второй результат > 2 и является простым числом.
3) создать два инстанса генератора и проверить, что каждый выдает свою последовательность, если это не синглтон.

Проверять три, пять, или 10000 чисел не имеет смысла, потому что такие тесты эквиваленты варианту с одним числом. Никто не собирается искать все ошибки при помощи юнит-тестов. С этим даже тяжелые функциональные и LH тесты не справляются. Задача юнит-тестов — sanity check, сделать быструю проверку, что в целом вроде бы ничего не сломано. Таких тестов обычно большое количество и они все должны выполняться достаточно быстро, чтобы их можно было запускать часто.

Здравствуйте, Basil2, Вы писали:

B> Окей. Как вы тогда напишете тесты для генератора простых чисел?
Юнит-тесты должны тестировать алгоритм как белый ящик. Т.е. в зависимости от алгоритма. Ну плюс ещё нагуглю какие-нибудь простые числа, или посчитаю на бумажке, или другой тулзой, (Maple какой-нибудь, или Wolfram) и впишу в юнит-тест найденные числа как константы.
Проверю code-coverage и допишу ещё тестов, чтобы добиться максимального покрытия.

Писать в юнит-тесте проверяльщик простоты числа как-то некузяво... А то в итоге придётся писать юнит-тест для юнит-теста.

Здравствуйте, ., Вы писали:

.>Писать в юнит-тесте проверяльщик простоты числа как-то некузяво... А то в итоге придётся писать юнит-тест для юнит-теста.

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

Здравствуйте, abibok, Вы писали:

A>Что еще известно про этот генератор? Если ничего и на выходе рандом, то:
A>1) получить одно число и проверить его на простоту и знак (больше нуля).
Я бы замокал генератор рандома и в тесте подставлял какое-то значение, ожидая конкретное число в результате.
Юнит-тест рандом генератора сделал бы отдельный. Конечно только в случае если он какой-то свой, а не используется "/dev/random", его тогда тестить не надо вообще.

A>2) если числа выдаются по порядку, то проверить, что первый результат = 2, второй результат > 2 и является простым числом.
Я бы просто забил список из нескольких элементов — 2, 3, 5, 7, 11. "результат > 2 и является простым числом" слишком хитрый assert, в юнит-тестах чем проще код, тем лучше.

A>3) создать два инстанса генератора и проверить, что каждый выдает свою последовательность, если это не синглтон.
+1. Хотя синглтонность не должна определяться генератором, IoC на это есть.

A>Проверять три, пять, или 10000 чисел не имеет смысла, потому что такие тесты эквиваленты варианту с одним числом. Никто не собирается искать все ошибки при помощи юнит-тестов. С этим даже тяжелые функциональные и LH тесты не справляются. Задача юнит-тестов — sanity check, сделать быструю проверку, что в целом вроде бы ничего не сломано. Таких тестов обычно большое количество и они все должны выполняться достаточно быстро, чтобы их можно было запускать часто.
Плюс поиск багов. Если юзер пришел и сказал, что когда я ввожу "42" и "розовый", то мне рисуется "слон", а должно рисоваться "величие".
Вместо того, чтобы щёлкать кнопками и лазить дебаггером на production, в подавляющем числе случаев возможно написать юнит-тест, который проваливается, потом фиксишь код, чтобы тест проходить начал.

10000 чисел могут быть полезны для performance тестов, которые отдельно.

Здравствуйте, ., Вы писали:

.>Юнит-тесты должны тестировать алгоритм как белый ящик. Т.е. в зависимости от алгоритма. Ну плюс ещё нагуглю какие-нибудь простые числа, или посчитаю на бумажке, или другой тулзой, (Maple какой-нибудь, или Wolfram) и впишу в юнит-тест найденные числа как константы.

Правильно. Эти константы вы скорее всего оформите в массив, и потом пробежитесь по ним в цикле.

А я хочу понять, чем так настроен против цикла abibok.

Здравствуйте, abibok, Вы писали:

B>>Окей. Как вы тогда напишете тесты для генератора простых чисел?
A>1) получить одно число и проверить его на простоту и знак (больше нуля).
A>2) если числа выдаются по порядку, то проверить, что первый результат = 2, второй результат > 2 и является простым числом.
A>3) создать два инстанса генератора и проверить, что каждый выдает свою последовательность, если это не синглтон.

A>Проверять три, пять, или 10000 чисел не имеет смысла, потому что такие тесты эквиваленты варианту с одним числом.

void IsPrime(unsigned int i)
{
    return i <= 3;
}

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

Здравствуйте, Basil2, Вы писали:

.>>Юнит-тесты должны тестировать алгоритм как белый ящик. Т.е. в зависимости от алгоритма. Ну плюс ещё нагуглю какие-нибудь простые числа, или посчитаю на бумажке, или другой тулзой, (Maple какой-нибудь, или Wolfram) и впишу в юнит-тест найденные числа как константы.
B>Правильно. Эти константы вы скорее всего оформите в массив, и потом пробежитесь по ним в цикле.
Вряд ли... Скорее будет n тестов для "специальных случаев". Ибо таких чисел не должно быть много и примерно эквивалентно сложности тестируемого кода. Упавший тест будет показывать ошибку конкретного случая.
На моей памяти цикл я писал лишь для некоего кода, обработки изображений. Т.е. входными данными были картинки.jpg. Цикл у меня пробегался по списку файлов в неком каталоге. Чтобы добавить новый тест, надо было просто скопировать картинку туда, ибо задавать картинку в коде теста — неудобно, а повторяться созданием @Test-метода для каждого нового файла в каталоге — лениво.

B>А я хочу понять, чем так настроен против цикла abibok.
"Остальные случаи проверяются циклом еще в одном тесте." — вот против этого. В юнит-тестах достаточно этого: "Для специальных случаев (0, 1, 2) делаются отдельные тесты."

Скажем, возьмём операцию умножения — специальные случаи — умножение на 0, на 1, числа разных знаков и переполнения. Для каждых из этих случаев будет отдельный тест метод. И не надо писать тест, умножающий числа 1-1000 в цикле. В лучшем случае он будет где-то в группе performance-тестов.

Здравствуйте, Basil2, Вы писали:

B>

B>void IsPrime(unsigned int i)
B>{
B>    return i <= 3;
B>}

B>Я правильно понимаю, что этот код успешно пройдет через ваши тесты?
Ещё раз, юнит-тесты пишутся для белого ящика, вместе с кодом имплементации.
Скорее всего на этапе написания юнит-тестов, у тебя будет какой-то документ (возможно крутая спека, а может быть пометки на салфетке, не важно) от заказчика с примерами — их ты сразу пишешь в виде тестов.
Если заказчику нужна функция проверки простоты для чисел не более четырёх, то эта имплементация — самая лучшая. В процессе развития продукта и уточнения спецификации выяснится, что для 5 тоже должно работать, то добавишь ещё один тест-кейс и перепишешь эту имплементацию.