Подсказки для тестирования информационно емкого унаследованного приложения

Получите копию Эффективная работа с устаревшим кодом Майкла Фезерса. В нем полно полезных советов по работе с большими непроверенными базами кода.

Еще одна хорошая книга - Шаблоны объектно-ориентированного реинжиниринга . Большая часть книги не посвящена объектно-ориентированному программному обеспечению. Полный текст доступен для бесплатной загрузки в формате PDF.

Из моего собственного опыта: попробуйте ...

• Автоматизировать сборку и развертывание
• Получить схему базы данных в системе контроля версий, если это еще не сделано . Обычно базы данных включают справочные данные, которые должны существовать для кода транзакции, прежде чем он сможет работать. Получите это тоже под контролем версий. Такие инструменты, как dbdeploy , могут помочь вам легко восстановить схему и ссылочные данные из последовательности дельт.
• Установите версию базы данных (и любые другие службы инфраструктуры) на рабочую станцию ​​разработчика. Это позволит вам работать с базой данных без постоянного обращения к администраторам баз данных. Это также быстрее, чем использование схемы на общем сервере в удаленном центре обработки данных. Все основные коммерческие серверы баз данных имеют бесплатные (как пиво) версии для разработки, которые работают в Windows (если вы застряли в незавидной ситуации разработки в Windows и развертывания в Unix).
• Перед тем, как начать работу над областью кода, напишите сквозные тесты, которые примерно охватывают поведение области, над которой вы работаете. Сквозной тест должен проверять систему извне - путем управления ее пользовательским интерфейсом или взаимодействия через сетевые службы - поэтому вам не нужно будет изменять код, чтобы установить его на место. Он будет действовать как (несовершенный) регрессионный тест и даст вам больше уверенности при рефакторинге внутренних компонентов системы в сторону структуры, которую легче поддаются модульному тестированию.
• Если есть ручные планы тестирования, прочтите их и посмотрите, что можно автоматизировать. Большинство планов ручного тестирования почти полностью написаны на основе сценариев и поэтому не представляют большой опасности для автоматизации
• . После того, как вы получили покрытие сквозным тестированием, реорганизуйте код в более слабосвязанные блоки по мере его изменения и / или расширения. Окружите эти модули модульными тестами.

Чего следует избегать:

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