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 тоже должно работать, то добавишь ещё один тест-кейс и перепишешь эту имплементацию.