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

Question

У меня грязная устаревшая система Delphi 7 для поддержки и развития. Я уже читаю "Эффективная работа с устаревшим кодом", и мне очень нравится эта книга.

Чтобы начать следовать советам в книге, я создал тестовый проект и попытался написать один тест. Для этого мне нужно добавить какой-то модуль в тестовый проект, но здесь кроется проблема: тестируемая система ужасно использует зависимости. Один блок использует другой блок, который использует другой блок и так далее, и так далее. Кажется, что большинство модулей прямо или косвенно используют один конкретный модуль, и этот модуль в свою очередь имеет 170 зависимостей в своем разделе использования. Существуют также косвенные циклические зависимости.

В настоящее время я пытаюсь добавить все модули устаревшей системы в тестовый проект, но я сталкиваюсь со всеми видами проблем, такими как "модуль xxx был скомпилирован с другой версией xxx" и другие.

Поэтому мне интересно, если я делаю что-то не так. Раньше я использовал модульное тестирование, но в моих собственных проектах, которые были меньше и с лучшей структурой и модульностью. Какие у меня есть варианты в этой ситуации? Я что-то пропустил?

Answer 1

У вас всегда будут зависимости в вашем коде. Ну, пока у вас есть повторное использование кода, у вас будут зависимости. Так как вы тестируете унаследованную систему, реструктуризация оптом исключена.

Так что вам просто нужно принять зависимости. Наиболее удобный и практичный подход - иметь единый проект модульных тестов. Этот проект содержит все ваши юнит-тесты. Используйте возможности вашей программы бегуна для одновременного запуска только определенных тестов.

Это приводит к тому, что ваш проект имеет тот же список блоков в своем файле.dpr, что и основной проект. Это то, что вы сейчас попробовали, и это правильный подход.

Ваша проблема звучит так, как будто вы делитесь каталогом DCU (выходным каталогом модуля) между основным проектом и проектом модульных тестов. И у вас есть разные варианты компиляции для двух проектов. Это наиболее вероятное объяснение ошибки, о которой вы сообщаете.

Есть несколько очевидных решений:

1. Совместите параметры компилятора для обоих проектов. Тогда они могут поделиться DCU.
2. Есть отдельные каталоги DCU для двух проектов.

Вариант 2 гораздо надежнее и является наилучшей практикой. Однако вы должны попытаться понять, почему параметры компилятора отличаются. Вполне возможно, что параметры вашего компилятора в новом проекте модульных тестов нужно будет изменить так, чтобы тестируемые модули компилировались и работали по желанию. В современном Delphi я бы использовал наборы опций для обеспечения согласованности опций компилятора.

Теперь могут возникнуть другие технические проблемы, с которыми вы сталкиваетесь, и мое объяснение ошибки может быть не совсем правильным, так как я должен немного догадаться. Но суть в том, что наличие того же списка блоков в ваших файлах.dpr - путь.