Без тестирования нельзя быть уверенным в надежности продукта. Подход "написали, запустили, заработало" не подходит для разработки надежных программ. Откладывать отладку и тестирование на завершение написания программы тоже не следует. Вероятность того, что откомпилированный код заработает достаточно мала. Отладить же огромный объем кода очень тяжело. Обычные опечатки и недочеты, ошибки в алгоритмах полностью нарушают взаимодействие между объектами программы, а значит потенциально будут приводить к сбоям в самых безобидных на вид местах. Пример очень прост, кто-нибудь определил для класса Vector3D оператор '-', который на самом деле складывает вектора. Найти эту ошибку будет нелегко. Многие компиляторы не позволяют отлаживать инлайновые функции - это тоже приводит к проблеме (либо запрещать инлайнить, либо отказаться от отладки этих функций). Однако никто не мешает тестировать любой объект.
Удобно использование макроса assert. В релизе все равно этих проверок не будет, а на стадии отладки и подготовки к релизу, можно будет найти множество ошибок. Удобно также написать свои макросы assert1, assert2, ... assert4, чтобы поддерживать разные уровни отладки. assert4 ставить везде, где только можно, а assert1 только в ключевых местах. Аналогично полезно ввести запись отладочного log-файла, сделав макросы dprintf1 ... dprintf4.
Всегда необходимо проверять правильность данных полученных от внешних библиотек ( открылся-ли файл, выделилась-ли память, и т.д. ) и от пользователя ( ввод с клавиатуры, файлов, и т.д. ). Пользователь может запросто указать неверные данные.
Хорошо организованное тестирование существенно уменьшает количество ошибок, попадающих в альфа/бета-версию. Количество ошибок, выявленных в бета-версии продукта, будет небольшим при хорошем тестировании на стадии разработки, однако выпуск бета-версий позволяет выявить кардинальные недоработки в программе.
Если компоненты образуют дерево и между ними нет циклических зависимостей, то низкоуровневые компоненты (которые не зависят от состояние программы в целом) легко тестируются с помощью тестеров. Примеры низкоуровневых компонент: image, point, vector, rectangle, ... Можно написать тестеры image-1.t.cpp, image-2.t.cpp, ... Которые будут производить тестирование компоненты image. Такое тестирование можно разбить по слоям, сначала оттестировав самый низкий слой компонент, зависящий только от внешних библиотек и не зависящий от каких-либо других компонент программы. Потом на слой выше - зависящих от внешних библиотек и от компонент самого низкого слоя. Так можно вести тестирование до тех пор, пока компонента имеет достаточно узкий диапазон применения, и заранее легко можно рассчитать, какой результат должен быть после работы этой компоненты. Таким тестированием удается реально выловить большинство мелких ошибок, серьезно нарушающих работу компоненты, также можно определить эффективность интерфейса и алгоритмов, реализованных в компоненте.
Когда несколько компонент связаны между собой данными сложного формата, то изолированное тестирование будет провести достаточно тяжело - нельзя гарантировать безошибочность самого тестера. Тогда можно взять некоторое множество компонент, и построить тестер, использующий их, и проверяющий результат работы всего комплекса. При таком тестировании больше времени уйдет на отладку, но это окупится, поскольку таким образом можно выявить серьезные ошибки в коде и дефекты интерфейсов объектов.
Или как это называется иначе - выпуск альфа-версии. Тестирование проводится уже почти полностью написанной программы. Цель такого тестирование - проверить выполняет-ли программа требуемые от нее функции. Обычно на этой стадии определяются дефекты алгоритмов, сложные ошибки, возникшие в результате неверного использования компонент или взаимодействия между ними, и недостатки функциональных возможностей. Если не проводить предварительно изолированное и промежуточное тестирование, то на этой стадии будет слишком много ошибок, чтобы их можно было легко исправить, поэтому придется долго выпускать тестовые версии.
Валерий Щедрин
<valery@forthpick.kiev.ua>