Есть два способа конструировать программное обеспечение: можно сделать его таким простым, чтобы отсутствие дефектов было очевидно, а можно сделать таким сложным, что в нем не будет очевидных дефектов.
Использование конкретных примеров устраняет такую случайно внесенную сложность и возможность случайности вообще. Пусть, например, дана последовательность:
3 1 4 1 5 9
Результат сортировки таков:
1 1 3 4 5 9
Никакой другой результат не подойдет. Другого ответа быть не может.
Конкретные примеры помогают проиллюстрировать общее поведение доступным и однозначным способом. Результатом добавления элемента в пустую коллекцию будет не только то, что она станет непустой: в коллекции должен появиться один элемент, причем он будет равен добавленному. Два или более элементов тоже означают, что коллекция не пуста, но это ошибка. Один элемент в коллекции, но с другим значением — тоже ошибка. Результатом добавления строки в таблицу является не просто то, что в ней становится на одну строку больше; следует проверить и то, что по ключу этой строки можно найти ее в таблице. И так далее.
Описывая поведение, тесты должны быть не только правильными — они должны быть точными.
Тестируйте во сне (и по выходным)
Раджит Аттапатту
Успокойтесь. Я имею в виду не оффшорные центры разработки программного обеспечения, не сверхурочную работу по выходным и не ночные смены. Я просто хочу обратить ваше внимание на то, какая огромная вычислительная мощь находится в нашем распоряжении. Точнее, как мало мы ее используем, чтобы хоть немного облегчить жизнь программиста. Вы постоянно сталкиваетесь с нехваткой вычислительной мощности в течение рабочего дня? Если так, то чем заняты ваши серверы тестирования в нерабочее время? Очень часто тестовые серверы простаивают ночью и по выходным. Вы можете использовать этот резерв.
• Был ли за вами грешок сохранить изменения в репозиторий, не прогнав все тесты? Одна из главных причин, по которой программисты не прогоняют наборы тестов перед сохранением изменений в репозиторий, — тестирование выполняется слишком долго. Когда горят сроки и растет давление, программист вполне естественно начинает срезать углы. Одно из решений этой проблемы — разбить набор тестов хотя бы на два профиля. Создайте меньший обязательный профиль тестов, который быстро отрабатывает и который можно будет запускать перед каждым сохранением. Все остальные профили (и обязательный на всякий случай тоже) можно автоматизировать и запускать по ночам, чтобы иметь к утру готовый результат.
• У вас была возможность проверить стабильность работы вашего продукта? Для выявления утечек памяти и других проблем со стабильностью критически важно проводить тесты, которые выполняются часами и сутками. Их редко запускают в дневное время, потому что они отнимают время и ресурсы. Зато можно автоматически выполнять нагрузочное тестирование в ночное время и по выходным. С 6 вечера пятницы до 6 утра понедельника у вас есть 60 часов, которые можно занять тестированием.
• Удается ли вам получить доступ к среде для тестирования производительности в удобное для вас время? Мне приходилось видеть, как команды ругаются одна с другой, выбивая себе доступ к среде для тестирования производительности. Мало кому удается получить в достаточном количестве удобное время для тестирования в рабочие часы, хотя по окончании рабочего дня серверы практически простаивают. В то же время серверы и сеть не так сильно загружены ночью и по выходным. Это идеальное время для выполнения тестов на производительность и получения надежных результатов.
• Не слишком ли много у вас разных конфигураций, чтобы тестировать их вручную? Часто продукт рассчитан на работу на нескольких платформах. Например, 32-разрядные и 64-разрядные версии для Linux, Solaris и Windows или просто для нескольких версий одной операционной системы. Дело осложняется еще и тем, что современные приложения допускают применение множества транспортных механизмов и протоколов (HTTP, AMQP, SOAP, CORBA и т. д.). Проверка всех возможных сочетаний требует очень много времени и чаще всего выполняется ближе к выпуску продукта в силу ограниченности ресурсов. Увы, некоторые ужасные ошибки обнаруживаются лишь на этой стадии, когда уже слишком поздно.