Тестирование класса, не указанного в разделе интерфейса

Question

Я новичок с контейнерами для инъекций зависимостей, и я пытаюсь использовать их в сочетании с Mocking.

Допустим, у меня есть контроллер и список (модель):

IBlahList = interface 
    property Items[AIndex: integer]: IBlah read GetItem; 
end; 

IController = interface 
    property List: IBlahList read GetList; 
end; 

Реализация IController будет выглядеть примерно так (обратите внимание, что это в implementaion разделе:

implementation 

TController = class (TInterfacedObject, IController) 
private 
    FList: IBlahList; 
    function GetList: IBlahList; 

public 
    constructor Create(const AList: IBlahList); 

end; 

И то, конечно, я бы зарегистрировал этот класс (а также один для IBlahList) с помощью GlobalContainer:

GlobalContainer.RegisterType<TController>.Implements<IController>; 

Я размещаю TController в разделе implementation, как это было предложено различными источниками (ну, Ник Ходжес в любом случае!), Так что мы не можем напрямую ссылаться на класс TController.

Теперь, просто сказать, что я хочу, чтобы проверить мою реализацию ICollection в модульном тесте:

procedure TestSomething 
var 
    LMockList: TMock<IBlahList>; 
    LController: IController; 
begin 
    LMockList := TMock<IBlahList>.Create; 

    // Oops, I can't do this, I can't access TController 
    LController := TController.Create(LMockList); 

end; 

Итак, мой вопрос, я должен переместить класс TController в мой interface раздел, так что я могу проверить это, или есть какой-то другой способ передать макет IBlahList контроллеру, который я еще не нашел?

Answer 1

Если у вас есть конкретный класс в разделе реализации, вы можете открыть заводскую функцию (то есть иметь в разделе интерфейса), которая создает IController с требуемыми параметрами.

Не имеет смысла иметь реализацию, которая не может быть создана, ИМО.

interface 

... 

function CreateController(AList: IBlahList): IController; 

implementation 

function CreateController(AList: IBlahList): IController; 
begin 
    Result := TController.Create(AList); 
end; 

Answer 2

Ну вы, вероятно, должно использовать фиктивные рамки в тестовых проектах, а также, но в этих случаях я обычно «обмануть» и переместить implementation туда, где мне это нужно с помощью DUnit условных переменный:

// In the real app, we want the implementation and uses clauses here. 
{$IFNDEF DUNIT} 
implementation 
uses 
    classes; 
{$ENDIF} 

type 
    TClassUnderTest = class(TObject) 
    // ... 
    end; 

// In test projects it is more convenient to have the implemenation and 
// uses clauses down here. 
{$IFDEF DUNIT} 
implementation 
uses 
    classes; 
{$ENDIF} 

Затем убедитесь, что любые тестовые проекты определяют условный var DUNIT и перемещают любые единицы, необходимые в объявлении TClassUnderTest, в раздел интерфейса. Последнее вы можете делать постоянно или под контролем условного условия DUNIT.

Answer 3

Я могу сказать: не слушайте Ника в этом случае.

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

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

Теперь вы удалили статическую зависимость TController и некоторого класса, который реализует IBlahList, но вы потянули другую (и намного хуже imo) зависимость: зависимость от контейнера DI.

Не помещайте класс в часть реализации устройства, чтобы предотвратить его непосредственное создание в вашем производственном коде. Также не устанавливайте зависимость от контейнера DI в этот блок.

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

Edit: Я предлагаю прочитать эту статью и обратить внимание на подчеркнутые части: http://www.loosecouplings.com/2011/01/dependency-injection-using-di-container.html

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

unit Interfaces; 

interface 

type 
    IBlahList = interface 
    property Items[AIndex: integer]: IBlah read GetItem; 
    end; 

    IController = interface 
    property List: IBlahList read GetList; 
    end; 

implementation 

end. 

-

unit Controller; 

interface 

uses 
    Classes, 
    Interfaces; 

type 
    TController = class (TInterfacedObject, IController) 
    private 
    FList: IBlahList; 
    function GetList: IBlahList; 
    public 
    constructor Create(const AList: IBlahList); 
    end; 

implementation 

... 

end. 

-

unit Registration; 

interface 

implementation 

uses 
    Interfaces, 
    Controller, 
    Spring.Container; 

initialization 
    GlobalContainer.RegisterType<TController>.Implements<IController>; 

end.