UnitTesting класса, который возвращает сложный набор данных

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

Я уже заказал Майкла. Книга Фезера , я занимаюсь рефакторингом Фаулера , и я сделал несколько примеров проектов с DUnit .

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

Почти 100% кода, над которым я работаю, содержит бизнес-логику в пользовательском интерфейсе, более того, все это процедурное программирование (за некоторыми исключениями). Приложение началось быстро и грязно и продолжилось как таковое.

Теперь написание тестов для всего приложения - бессмысленная задача в моем случае, но я хотел бы попробовать unittest что-то, что мне нужно реорганизовать.

Одна из сложных задач, которые выполняет один большой "класс бизнес-логики TForm", - это считывание данных БД, выполнение некоторых вычислений и заполнение компонента планировщика. Я хотел бы удалить часть чтения данных и вычислений БД и передать эту задачу новому классу. Конечно, это способ улучшить текущий дизайн, это не лучший способ начинать с нуля, но я бы хотел сделать это, потому что данные, возвращаемые этим новым классом, полезны и другими способами, например, теперь я меня просили отправлять по электронной почте уведомления о данных планировщика.

Поэтому, чтобы избежать массовых операций копирования и вставки, мне нужен новый класс.

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

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

Следующие моменты мне не ясны:

1) как протестировать сложный набор данных? Следует ли мне запустить рабочее приложение, сохранить один набор результатов в xml и написать тест, в котором я использую TClientDataSet, содержащий эти XML-данные?

2) Насколько мне нужно заботиться о TSchedulerData? То есть я не уверен на 100%, что буду использовать TSchedulerData, может быть, я буду придерживаться набора данных, в любом случае мысль о создании сложных тестов, которые будут отброшены через 2 недели, не привлекает DUnitNewbee. Во всяком случае, наверное, так это работает. Я не могу представить, с каким количеством ошибок я столкнулся бы без теста.

Последнее замечание: я знаю, что кто-то думает, что переписывание с нуля - лучший вариант, но это не вариант. «Приложение огромное, и оно продается сегодня, и сегодня необходимы новые функции, чтобы не уйти из бизнеса». Мне так сказали, в любом случае рефакторинг может спасти мне жизнь и продлить жизнь приложения.