Тестируйте точно и конкретно Кевлин Хенни

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

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

Если спросить у программиста, что он собирается тестировать, в подавляющем большинстве случаев он ответит что-то вроде: «Нужно проверить, что результат будет отсортированной последовательностью элементов». Это правда, но не вся правда. Если программисту предложить уточнить проверяемое условие, то многие добавят, что результирующая последовательность должна быть той же длины, что и исходная. Верно, но и этого мало. Возьмем, например, последовательность:

3 1 4 1 5 9

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

3 3 3 3 3 3

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

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

Даже такая формулировка постусловия не гарантирует, что это хороший тест. Хороший тест должен легко читаться. Он должен быть достаточно понятным и простым, чтобы сразу можно было увидеть, корректен он или нет. Если у вас нет готового кода для проверки того, что последовательность отсортирована и что одна последовательность содержит перестановку значений другой, не исключено, что тестирующий код окажется сложнее, чем тестируемый. Как заметил Тони Хоар (Tony Hoare):

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

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

3 1 4 1 5 9

Результат сортировки таков:

1 1 3 4 5 9

Никакой другой результат не подойдет. Другого ответа быть не может.

Конкретные примеры помогают проиллюстрировать общее поведение доступным и однозначным способом. Результатом добавления элемента в пустую коллекцию будет не только то, что она станет непустой: в коллекции должен появиться один элемент, причем он будет равен добавленному. Два или более элементов тоже означают, что коллекция не пуста, но это ошибка. Один элемент в коллекции, но с другим значением — тоже ошибка. Результатом добавления строки в таблицу является не просто то, что в ней становится на одну строку больше; следует проверить и то, что по ключу этой строки можно найти ее в таблице. И так далее.

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

Загрузка...