TDD в устаревшем коде - нарушение зависимостей конструктора

Question

В приложении JAVA у меня есть следующий класс:

public class PathEditor extends DocumentListBase {
    public PathEditor(Paths paths, Frame frame) {
        super(frame);

        // Some logic is being executed here.
    }
}

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

Пути

public class Paths {
}

Кадр

public class Frame extends DocumentListItemBase {
    public Frame(DocumentBase parent) {
        super(parent);
    }
}

DocumentListItemBase

public class DocumentListItemBase extends DocumentBase {
    public DocumentListItemBase(DocumentBase parent) {
        super(parent);
    }
}

DocumentBase

public class DocumentBase {
    public Document _document;

    public DocumentBase(DocumentBase parent) {
    }

    public Document getDocument() {
        return this._document;
    }
}

DocumentListBase

public class DocumentListBase extends DocumentBase {
    public DocumentListBase(DocumentBase parent) {
        super(parent.getDocument());
    }
}

Document

public class Document extends DocumentBase {
    public Document(DocumentBase parent) {
        super(parent);
    }
}

Теперь мне нужно добавить функцию к PathEditor, которую я хотел бы добавить, используя TDD подход. Вы можете увидеть проблему, я не могу создать PathEditor в контексте UT, так как это зависит от конкретных типов.

Обратите внимание, что конкретные типы делают некоторые logi c в своем конструкторе, такие как вызов БД поэтому их нельзя добавлять в контексте «UT».

Очевидно, что этот класс необходимо реорганизовать, чтобы разрешить TDD подход, но этот класс НЕ содержит никаких тестов. Каков предпочтительный подход, чтобы сделать этот класс тестируемым, используя наименьшие возможные изменения, чтобы я был уверен, что не нарушу ничего, что делает конструктор?

Answer 1

1. Если в существующем коде нет тестов, ваша первая задача - добавить тесты перед изменением этого кода. Это сформирует базовую линию для ваших изменений, гарантируя, что вы не введете регрессию.
2. Ни один из показанных конкретных классов не является final, поэтому, например, Paths и Frame могут быть подклассифицированы как тестирование макетов, если это облегчает ситуацию. Менее важно, что зависимости являются конкретными, если зависимости вводятся и расширяются.
3. Если конструкторы полагаются на зависимости, которые не введены, и вы будете sh проверять такие классы без вызова этих зависимостей, вы можете быть вынуждены реорганизовать эти классы. Начните с # 1 и напишите (хотя бы интеграционные) тесты перед рефакторингом.