Как определить тестовые примеры для модульных тестов?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

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

ЛЮДИ ПОЖАЛУЙСТА, КОММЕНТАРИЙ ПОЧЕМУ ВЫ ДУМАЕТЕ, ЧТО ЭТО БЫЛО ДОЛЖНЫ ДВЕ ЗАВИСИМОСТИ:)

Ответ 4

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

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

также проверяют случаи ожидаемого исключения, если применимо

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

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

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