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

Question

Я работаю над очень большим устаревшим приложением, интенсивно использующим данные. И база кода, и база данных имеют огромный масштаб. Большая часть бизнес-логики распространяется на все уровни, включая хранимые процедуры.

Есть ли у кого-нибудь какие-либо предложения о том, как начать применять «модульные» тесты (технически интеграционные тесты, потому что им нужно тестировать по уровням для одного аспекта практически любого данного процесса) в приложении эффективным способом? Текущая архитектура не может легко поддерживать любые типы инъекций или насмешек. Новый код пишется для облегчения тестирования, но как насчет старого кода? Из-за сильной зависимости от самих данных и бизнес-логики в базе данных я в настоящее время использую встроенный sql для поиска данных, которые можно использовать для тестирования, но это отнимает много времени. Создание представлений и / или хранимых процедур будет недостаточно.

Какие подходы вы использовали (если применимо)? Что сработало? Что не так и почему? Мы ценим любые предложения. Спасибо.

Answer 1

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

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

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

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

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

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

Answer 2

«Тестирование устаревших приложений», основные моменты:

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

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

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

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

http://application -management.cioreview.com / Whitepaper / тестирование-наследие-приложений модернизация-УЖР-529.html