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

Традиционно, автоматические тесты относятся к следующим категориям:

Unit-тесты

изолируют определённый компонент и тестируют функциональность только этого компонента. Это самый распространённый и самый эффективный вид тестов, поскольку окружающие обстоятельства не влияют на функциональность компонента и его тестирование. Зависимость от других компонентов применительно к тестированию означает, что любые потенциальные ошибки, содержащиеся в этих компонентах, приведут к провалу теста, даже если сам тестируемый компонент в норме. Unit-тесты обходят эти зависимости; если компонент по своей природе зависит от других компонентов (например, адаптер или вид), общепринято писать подставные объекты, имитирующие необходимые компоненты с помощью очень простой реализации.

Интеграционные тесты

дают уверенность, что взаимодействие компонентов работает как предполагалось. В то время, как unit-тесты покрывают индивидуальную ответственность (?) компонента, интеграционные тесты покрывают всё множество компонентов, интегрированных в под-процесс приложения. Часто интеграционные тесты имеют смысл только в том случае, когда вы уже выполнили unit-тесты для компонентов, участвующих во взаимодействии. Если у вас нет unit-тестов и интеграционный тест валится, вы не можете сказать наверняка, привёл ли к падению теста один из компонентов, или же тест провален потому, что не работает интеграция. К сожалению, интеграционные тесты в Zope называют функциональными тестами, из-за чего их сложно отличить от настоящих функциональных тестов.

Функциональные тесты

обращаются с приложением как с чёрным ящиком и не вникают в тонкости его внутреннего устройства. Они видят то, что видит пользователь и выполняют те действия, которые должен выполнять пользователь, в идеале — через пользовательский интерфейс. В случае веб-приложения, тесты могут просто имитировать управляемый пользователем веб-браузер, например. Функциональные тесты не зависят от платформы разработки и языка программирования приложения, особенно в случае веб-приложений. Существует многочисленный инструментарий для функционального тестирования веб-приложений, из которого, возможно, самым популярным пакетом является Selenium.

Правильный подход

Наличие автоматических тестов само по себе не даёт гарантий высокого качества программного продукта. Тестовые случаи могут быть неэффективными и, таким образом, бесполезными, если они не покрывают реалистических обстоятельств. С другой стороны, тесты, не выполняющие проверку граничных случаев, могут легко скрыть ошибки. В сообществе Zope доказал свою пригодность следующий подход, полностью описываемый следующими положениями:

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

• Когда добавляется новая функциональность, пишется новый тестовый случай, обеспечивающий покрытие тестами всей новой функциональности. Это гарантирует, что код будет работать правильно не только сейчас, но и в будущем.

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

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