97 этюдов для программистов. Опыт ведущих экспертов

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

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

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

3 1 4 1 5 9

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

1 1 3 4 5 9

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

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

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

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

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

• Был ли за вами грешок сохранить изменения в репозиторий, не прогнав все тесты? Одна из главных причин, по которой программисты не прогоняют наборы тестов перед сохранением изменений в репозиторий, — тестирование выполняется слишком долго. Когда горят сроки и растет давление, программист вполне естественно начинает срезать углы. Одно из решений этой проблемы — разбить набор тестов хотя бы на два профиля. Создайте меньший обязательный профиль тестов, который быстро отрабатывает и который можно будет запускать перед каждым сохранением. Все остальные профили (и обязательный на всякий случай тоже) можно автоматизировать и запускать по ночам, чтобы иметь к утру готовый результат.

• У вас была возможность проверить стабильность работы вашего продукта? Для выявления утечек памяти и других проблем со стабильностью критически важно проводить тесты, которые выполняются часами и сутками. Их редко запускают в дневное время, потому что они отнимают время и ресурсы. Зато можно автоматически выполнять нагрузочное тестирование в ночное время и по выходным. С 6 вечера пятницы до 6 утра понедельника у вас есть 60 часов, которые можно занять тестированием.

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