Как определить тестовые случаи для юнит-тестов?

Question

Я только что начал модульное тестирование и написал несколько коротких тестов, чтобы проверить, правильно ли работает функция isPrime ().

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

Сколько я должен проверить? Как мне решить, какой тест? Какие здесь лучшие практики?

Один из подходов состоит в том, чтобы сгенерировать 1000 простых чисел, а затем перебрать их все, другой - просто выбрать 4 или 5 и проверить их. Как правильно поступить?

Answer 1

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

Answer 2

Вы хотите проверить крайние случаи. Какое простое число должен обрабатывать ваш метод? Это будет зависеть от того, какое представление (тип) вы использовали. Если вас интересуют только небольшие ( действительно относительный термин при использовании в теории чисел) простые числа, вы, вероятно, используете int или long. Протестируйте несколько самых простых простых чисел в выбранном вами представлении. Убедитесь, что вы также проверили некоторые не простые числа. (Это гораздо проще проверить самостоятельно.)

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

Answer 3

"Остерегайтесь ошибок. Я доказал корректность приведенного выше алгоритма, но еще не проверял его."

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

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

Answer 4

в общем, протестируйте столько случаев, сколько вам нужно, чтобы чувствовать себя комфортно / уверенно

также, в общем, проверьте базовый / нулевой регистр, максимальный регистр и хотя бы один медианный / средний регистр

также тестируйте случаи ожидаемых исключений, если применимо

если вы не уверены в своем простом алгоритме, то непременно проверьте его с первыми 1000 простыми числами, чтобы получить уверенность

Answer 5

Спроси себя. Что именно я хочу проверить. И проверить самое главное. Проверьте, чтобы убедиться, что он в основном выполняет то, что вы ожидаете, в ожидаемых случаях.

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

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

Если вы хотите доказать, что метод поиска простых чисел является ПРАВИЛЬНЫМ - 100000 простых чисел будет недостаточно :) Но вы не хотите проверять последнее (вероятно) ...

Только ты знаешь, что хочешь проверить! :)

PS Я думаю, что использование циклов в модульных тестах не всегда неправильно, но я бы дважды подумал, прежде чем делать это. Тестовый код должен быть ОЧЕНЬ прост. Что если что-то пойдет не так и в вашем тесте будет ошибка? :) Однако вам следует избегать дублирования тестового кода как обычного дублирования кода. Кто-то должен поддерживать тестовый код.

ЛЮДИ, ПОЖАЛУЙСТА, СКАЖИТЕ, ПОЧЕМУ ВЫ ДУМАЕТЕ, ЧТО ЭТО СТОИТ ДВУХ ГОЛОСАМИ

Answer 6

«Если стоит построить, стоит проверить»
«Если не стоит тестировать, почему вы тратите свое время на работу над этим?»

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

Ох и "Я только что нашел последнюю ошибку" - ХА ХА.

Answer 7

Чтобы быть уверенным, вам придется протестировать их все. : -)

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

Другое дело - убедиться, что вы понимаете пределы представления чисел, что бы это ни было. По крайней мере, это установит верхний предел размера, который вы можете проверить. Например, если вы используете 32-битное целое число без знака, вы никогда не сможете протестировать значения больше 4G. Возможно, ваш лимит будет ниже, в зависимости от деталей вашей реализации.

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

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

Кроме того, подумайте, как вы собираетесь «сгенерировать» свой список простых чисел для тестирования. Можете ли вы доверять этому списку, чтобы быть правильным? Как и кем были проверены эти цифры?

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

Answer 8

Несколько вопросов, ответы могут сообщить ваше решение:

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

Редактировать: Хм, так что советовать в вашем конкретном сценарии. Так как вы начали писать модульные тесты вчера, у вас может не хватить опыта для выбора среди всех этих факторов. Позвольте мне помочь вам:

• Этот код, вероятно, не слишком важен (никто не умирает, никто не вступает в войну, никому не предъявляется иск), поэтому тестирование будет хорошим.
• Реализация, вероятно, не изменится (методы простых чисел хорошо известны), поэтому нам не нужны тесты для поддержки этого. Если реализация действительно меняется, это, вероятно, связано с наблюдаемым ошибочным значением. Это можно добавить в качестве нового теста во время изменения.
• Публичный договор об этом не изменится.
• Получите 100% покрытие кода. Нет причин писать код, который тест не посещает в этих обстоятельствах. Вы должны быть в состоянии сделать это с небольшим количеством тестов.
• Если вас волнует, что делает код, когда вызывается ноль, проверьте это.
• Небольшое количество тестов должно выполняться быстро. Это позволит им часто запускаться (как разработчиками, так и автоматическими). ​​

Я бы протестировал 1, 2, 3, 21, 23, "большое" простое число (5 цифр), "большое" не простое число и 0, если вам интересно, что это делает с 0.