Советы по тестированию унаследованных приложений с интенсивным использованием данных

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

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

По собственному опыту: попробуй ...

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

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

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

«Тестирование модернизации устаревших приложений» подчеркивает:

1. Общий обзор того, как создаются тесты в AscentialTest

2. Способы преобразования устаревших объектов в новую платформу Компоненты определения объекта

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

Для получения дополнительных сведений об использовании устаревшего приложения для тестирования проверьте здесь:

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html.

Как упоминалось ранее, есть несколько очень хороших книг. Настоятельно рекомендуется взглянуть на «Эффективная работа с устаревшим кодом».

Что-то, что вы могли бы сделать, - это следовать подходу, основанному на данных, наблюдать за своим приложением и вводить тесты там, где у вас больше «проблем». Может оказаться полезным полудетерминированный подход: https://link.medium.com/zY9Tysfne9