PHPUnit: можно ли одновременно замокапить и класс, и интерфейс?

Question

[Станислав]

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

У нас есть интерфейс, который мы хотим отлавливать через try catch. Реальных классов, реализующих этот интерфейс, еще не существует, мы делаем этот отлов только на случай, если библиотека, в которой этот интерфейс реализуется, получит новые классы исключений с этим интерфейсом. В коде, который работает вокруг этого try catch, у данного исключения используется метод getMessage().

Соответственно, нам нужно получить мок интерфейса, у которого будет метод getMessage(). Просто взять и указать данный метод через setMethods() невозможно - PHPUnit проверит, есть ли такой метод в интерфейсе, и выдаст ошибку. И в итоге нам нужно получить мод интерфейса с дополнительным методом.

Вопрос: мы можем взять реально существующий класс Exception, указать неким образом, что он должен реализовывать наш интерфейс, и получить такой мок? Или нативными средствами PHPUnit данная задача не решается?

Answer 1

[vldud]

Вроде бы не решается.

С моей точки зрения, ваша задумка не очень логична. Вот реализуете классы, тогда и пишите тесты конкретно под них.

Comments

[Станислав]

Я согласен с вашим уточнением. Но интересно, можно ли все-таки так это сделать. В целом я пока что решил это через создание прямо рядом с тестом FakeException, который реализует все, что нужно, и это выглядит вполне пристойным решением, но вдруг.

[Максим Федоров]

Границы очерчены и нужно под это тесты написать — все верно
А тест — как первая реализация, проверяющая код

Answer 2

[Максим Федоров]

Не надо плодить классы. Воспользуйтесь тогда анонимным классом (для таких задач их и придумали) прямо в коде:

new class implement YourInterface {
    // тут методы, которые интерфейс содержит
    // тут методы, которые вы будете вызывать
}

Comments

[Станислав]

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

[Максим Федоров]

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

[BoShurik]

Станислав, как вариант - передать в этот класс мок интерфейса, если я правильно понимаю задачу

[Станислав]

BoShurik, а подробнее? Не понял вашего ответа.

[BoShurik]

Станислав,

$instance = new class ($this->createMock(YourInterface::class)) extends \Exception implements YourInterface {
    private $mock;

    public function __construct(YourInterface $mock, $message = "", $code = 0, Throwable $previous = null) {
        parent::__construct($message, $code, $previous);

        $this->mock = $mock;
    }

    public function interfaceMethod($parameter)
    {
        return $this->mock->interfaceMethod($parameter);
    }
};

[BoShurik]

Станислав, но возможно ваш интерфейс правильно тогда наследовать от \Throwable

[Станислав]

BoShurik, я понял ваш ответ, и наверное он по сути своей верный. Только подскажите, он отличается чем-либо от того ответа, в ветке которого мы общаемся? Если да, то опубликуйте, пожалуйста, свой комментарий как ответ с разъяснением этого отличия. Если нет, помечу данный ответ как верный, чтобы людям потом удобно было :-)

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

[BoShurik]

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

Думаю, это оптимальное решение. Оно теряется за формулировкой вопроса :)

Только подскажите, он отличается чем-либо от того ответа, в ветке которого мы общаемся?

Нет, просто логическое продолжение предложенного Максим Федоров, пусть поправит ответ (и лучше с упоминанием оптимального решения :)