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

Например, требования к тройственному сравнению, такому как String.compareTo в Java или strcmp в C, таковы: результат должен быть отрицательным, если левая часть меньше правой, положительным, если левая часть больше правой, и нулем, если они равны. Такого рода сравнение используется во многих API, включая функцию сравнения для qsort в C и compareTo в интерфейсе Java Comparable. Обычно в реализациях для обозначения меньше и больше используются конкретные значения -1 и +1, в связи с чем программисты иногда ошибочно предполагают, что именно эти значения и выражают действительное требование, и пишут тесты, основанные на этом предположении.

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

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

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

Тестируйте точно и конкретно

Кевлин Хенни

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

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

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

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

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

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

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

Тестируйте во сне (и по выходным)

Раджит Аттапатту

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

• Был ли за вами грешок сохранить изменения в репозиторий, не прогнав все тесты? Одна из главных причин, по которой программисты не прогоняют наборы тестов перед сохранением изменений в репозиторий, —