Проблемы приведения типов интерфейсов и решения с помощью Spring.Mocking в Delphi

Delphi , Программа и Интерфейс , Интерфейс

При работе с интерфейсами в Delphi и использовании фреймворка для мокирования Spring.Mocking может возникнуть проблема с приведением типов, которая проявляется в виде ошибки при выполнении приведения одного интерфейса к другому, несмотря на то, что один интерфейс является производным от другого. В данном случае пользователь столкнулся с проблемой, когда приведение типа IYetAnotherIntf к IIntfToMock вызвало ошибку EIntfCastError.

Контекст проблемы

В коде, предоставленном пользователем, есть класс TClassToTest, который использует интерфейс IIntfProvider для получения экземпляра IYetAnotherIntf, который затем приводится к типу IIntfToMock. В тестовом методе Execute создаются моки для интерфейсов IIntfToMock, IYetAnotherIntf и IIntfProvider. При попытке приведения IYetAnotherIntf к IIntfToMock в методе MethodeToTest класса TClassToTest возникает ошибка.

Подтвержденное решение

Разработчики Spring.Mocking указали, что моки автоматически возвращают мок, если метод возвращает интерфейс, и всегда один и тот же экземпляр. Это означает, что для фабричных моков не требуется указывать ожидаемое поведение. Достаточно получить мок, возвращаемый фабрикой, и указать его поведение. Также было обнаружено, что в коде есть баг: мок пытается выполнить приведение для любого интерфейса, независимо от его "мокируемости". В результате было добавлено проверка, и теперь ошибка будет возникать позже, если попытаться использовать мок как мокируемый интерфейс.

Альтернативное решение

Для поддержки других интерфейсов на моке необходимо явно указать это. Это следует из того же принципа, что и при реализации интерфейсов в классах. Если класс реализует только IYetAnotherIntf и хранит его в переменной интерфейса этого типа, но затем пытается привести к as, Supports или QueryInterface, это приведет к сбою.

Обновленное решение (12.04.2021)

В обновлении было указано, что два упомянутых бага устранены:

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

Пример кода

procedure Execute;
var
  ProvMock: Mock<IIntfProvider>;
  YetiMock: Mock<IYetAnotherIntf>;
  Instance: TClassToTest;
begin
  // Использование типа извлечения здесь, &lt;IYetAnotherIntf&gt; не нужен
  YetiMock := Mock.From(ProvMock.Instance.YetAnotherIntfFactory);
  // Сделаем поведение строгим, чтобы он не возвращал False, если нет совпадения
  YetiMock.Behavior := TMockBehavior.Strict;
  YetiMock.Setup.Returns(True).When(Args.Any).DoSth(nil, nil);
  // Это внутренне добавит IIntfToMock в перехваченные интерфейсы
  // Поскольку возвращает Mock<IIntfToMock>, можно также указать его поведение
  YetiMock.AsType<IIntfToMock>;
  Instance := TClassToTest.Create(ProvMock);
  if Instance.MethodeToTest then
    System.Writeln('Все работает корректно :)')
  else
    System.Writeln('Что-то пошло не так :(');
end;

Обратите внимание, что моки инициализируются автоматически, поэтому не требуется вызывать Mock<T>.Create.

Заключение

При работе с интерфейсами и мокировании в Spring.Mocking важно правильно указывать поведение моков и поддерживаемые интерфейсы. После устранения упомянутых багов, использование мокирования становится более надежным и удобным.

Создано по материалам из источника по ссылке.

Проблема заключается в некорректном приведении типов интерфейсов при использовании фреймворка Spring.Mocking в Delphi, что приводит к ошибке при выполнении теста.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Интерфейс ::