Строгость в захвате тестов для юнит-тестирования

Question

Допустим, у нас есть простая функция, определенная на псевдоязыке.

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

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

По моему опыту, некоторые люди лучше фиксируют граничные условия, чем другие. Вопрос в том, «Как вы узнаете, когда вы« сделали »захват контрольных примеров»?

Мы можем начать перечислять случаи сейчас, и некоторые умные люди, несомненно, подумают о «еще одном» случае, который не охватывался ни одним из предыдущих.

Answer 1

Не тратьте слишком много времени, пытаясь придумать каждое граничное условие. Ваши тесты не смогут поймать каждую ошибку в первый раз. Идея состоит в том, чтобы иметь тесты, которые довольно хороши , а затем каждый раз, когда ошибка выдает , напишите новый тест специально для этой ошибки, чтобы вы никогда больше о нем не узнали. 1009 *

Еще одно замечание, которое я хочу сделать об инструментах покрытия кода. На таких языках, как C # или Java, где у вас есть много методов get / set и аналогичных методов, вы должны не стрелять для 100% покрытия. Это означает, что вы тратите слишком много времени на написание тестов для тривиального кода. Вы только хотите 100% охватить вашу сложную бизнес-логику. Если ваша полная кодовая база ближе к 70-80% покрытия, вы делаете хорошую работу. Если ваш инструмент покрытия кода позволяет использовать несколько показателей покрытия, лучшим из них является «покрытие блоков», которое измеряет покрытие «базовых блоков». Другими типами являются покрытие класса и метода (которое не дает вам такой большой информации) и покрытие линии (что слишком мелко).

Answer 2

Как вы узнаете, когда вы закончите захват контрольных примеров?

Вы не можете. Вы не можете получить 100%, за исключением самых тривиальных случаев. Также 100% покрытие (линий, путей, условий ...) не говорит о том, что вы достигли всех граничных условий.

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

Отрывок из Искусство тестирования программного обеспечения Гленфорда Дж. Майерса:

1. Если входное условие задает диапазон значений, запишите контрольные примеры для концов диапазона и недопустимые входные тесты для ситуаций, выходящих за пределы.
2. Если входное условие задает количество значений, запишите контрольные примеры для минимального и максимального количества значений и одного под этими значениями и за их пределами.
3. Используйте для каждого условия вывода рекомендацию 1.
4. Используйте для каждого условия вывода рекомендацию 2.
5. Если вход или выход программы является упорядоченным набором, обратите внимание на первый и последний элементы набора.
6. Кроме того, используйте свою изобретательность для поиска других граничных условий

( Я вставил только минимум по соображениям авторского права. )

Пункты 3. и 4. выше очень важны. Люди склонны забывать граничные условия для выходов. 5. все в порядке. 6. действительно не помогает: -)

Короткий экзамен

Это сложнее, чем кажется. Майерс предлагает этот тест:

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

Помните, что равносторонний треугольник - это тот, в котором нет двух равных сторон, тогда как равнобедренный треугольник имеет две равные стороны, а равносторонний треугольник имеет три стороны равной длины. Кроме того, углы, противоположные равным сторонам в равнобедренном треугольнике, также равны (из этого следует, что стороны, противоположные равным углам в треугольнике, равны), и все углы в равностороннем треугольнике равны.

Напишите ваши контрольные примеры. Сколько у тебя? Майерс задает 14 вопросов о вашем наборе тестов и сообщает, что высококвалифицированные профессиональные программы в среднем 7,8 из возможных 14.

Answer 3

С практической точки зрения я создаю список тестов, которые, по моему мнению, должны пройти до принятия. Я проверяю их и автоматизирую, где это возможно. Исходя из того, сколько времени я оценил для выполнения задания или сколько времени мне дали, я расширяю свое тестовое покрытие, чтобы включить элементы, которые должны пройти до принятия. Конечно, грань между «должен» и «должен» субъективна. После этого я обновляю автоматизированные тесты по мере обнаружения ошибок.

Answer 4

@ Keith

Я думаю, что вы прибили это, важно понять охват кода, если вы хотите увидеть, как вы «сделали», но я думаю, что 100% - это немного нереальная цель. Стремление к 75-90% даст вам достаточно хорошее освещение, не выходя за борт ... не проверяйте себя ради достижения 100%, потому что в этот момент вы просто тратите свое время.

Answer 5

Хороший инструмент покрытия кода действительно помогает.

100% покрытие не означает, что оно определенно адекватно протестировано, но это хороший показатель.

Для .Net NCover достаточно хорош, но больше не является открытым исходным кодом.

---

@ Майк Стоун - Да, возможно, это должен был быть "высокий охват" - мы стремимся к минимуму 80%, после примерно 95% это обычно уменьшает отдачу, особенно если у вас есть код пояса и скобок.