Какой смысл mock объектов для юнит тестирования своего кода?

Question

[Tokenchik]

Всем привет, использую phpunit для тестов, столкнулся с непонимаем смысла мока классов и их методов.
Ситуация которая мне понятна - мок http клиента который возвращает конкрентный результат и завязан на внешний сервис, но как быть с простыми классами, которые не связаны с внешним миром?
Есть небольшой пример:

<?php
class SomeClass
{
    public function doSomething(): string
    {
        return 'foo';
    }
}

<?php
use PHPUnit\Framework\TestCase;

class StubTest extends TestCase
{
    public function testStub(): void
    {
        // Создать заглушку для класса SomeClass.
        $stub = $this->createMock(SomeClass::class);

        // Настроить заглушку.
        $stub->method('doSomething')
             ->willReturn('foo');

        // Вызов $stub->doSomething() теперь вернёт 'foo'.
        $this->assertSame('foo', $stub->doSomething());
    }
}

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

Comments

[Александр]

Unit Test - модульное решение. Ваш класс можно считать как отдельный , независящий от другого мира. Он не должен знать сам по себе внешние данные и зависеть от них. Суть этих тестов именно проверит функциональность модуля

[Александр]

Вот https://phpunit.readthedocs.io/ru/latest/test-doub...

[Tokenchik]

Александр, подскажите а кто решает что класс считается как отдельный? Это рекомендация или выбор разработчика? По той ссылке что вы скинули, вроде четко сказано - что в случае когда нет необходимых данных для теста, а если предположим они у меня есть? Мокать нужно все или нет?

[Александр]

Tokenchik, Отрывок из книги.Обычно зависимость - это интерфейс, который имеет несколько реализа-
ций. Использование реальных реализаций этого интерфейса во время unit-
тестирования - плохая идея, поскольку там могут проводиться те самые опера-
ции ввода-вывода, замедляющие тестирование и не дающие провести тести-
рование этого модуля в изоляции. Прогон unit-тестов должен быть быстр как
молния, поскольку запускаться они будут часто и важно, чтобы разработчик
запустив их не потерял фокус над кодом. Написал код - прогнал тесты, еще
написал код - прогнал тесты. Быстрые тесты позволят ему оставаться более
продуктивным, не позволяя отвлекаться. Решение в лоб задачи изоляции
класса от зависимостей - создание отдельной реализации этого интерфейса,
предназначенного просто для тестирования.

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

[Tokenchik]

Александр, можно попросить ваш большой коммент вынести в ответ, я после небольших обсуждений почему его как один из ответов.
У меня есть тогда конкретный вопрос с примером, представим есть класс, который генерирует специальным образом строки (скажем аналогично uuid), как тестируется такой класс? Создается его мок в мок метода подкиываем пример того что он возвращает? или не мокаем и проверяем что результат соотвествует необходимым требования (кол-байт, спей-разделителей и т.д.) Мне бы чуток примеров, чтобы отчего-то оттолкнуться )

Answer 1

[HellWalk]

Смысл моков - эмулировать объекты с определенным поведением.

Самый банальный пример, помимо http запросов, это эмулирование неправильных объектов.

Допустим, у вас есть сервис, который обрабатывает какой-то объект. Объект написан хорошо, с валидацией данных, и его поведение корректное. Но чтобы вам написать качественный сервис - он не должен полагаться на то, что другой объект ведет себя корректно. Он должен дополнительно проверять граничные ситуации. И разумеется, на такие кейсы нужно написать тесты, а как их написать, если тестируемый объект написан так, что он ведет себя корректно? Вот здесь и приходят на помощь моки.

В phpunit есть функционал подсчета покрытия кода тестами - попробуйте на каком-нибудь относительно небольшом модуле добиться 100% покрытия кода тестами - вам обязательно придется использовать хитрые моки, эмулирующие нестандартное поведение объектов.

P.S. Если вы недавно знакомы с юнит-тестами - непонимание моков нормально. Если будете стремиться писать надежный код, с качественным покрытием кода тестами (здесь самое сложное - предугадать все плохие кейсы, которые будут пытаться сломать ваш код) - понимание придет.

Comments

[Tokenchik]

Допустим, у вас есть сервис, который обрабатывает какой-то объект. Объект написан хорошо, с валидацией данных, и его поведение корректное. Но чтобы вам написать качественный сервис - он не должен полагаться на то, что другой объект ведет себя корректно.

Тут сразу в голову приходит пример с тем что у класса внутри есть другие классы, в этом случае мы мокаем и их тоже? или мок только тестируемого класса, а все зависимости собирать из оригинальных?

[HellWalk]

Tokenchik, в теории да, юнит тест не должен вообще завязываться на другие классы. С другой стороны, с точки зрения практики, когда тестом покрывается ~50% кода - то хорошо бы, для начала, просто доводить этот показатель до 80-90%, плюс не лениться думать над плохими кейсами, которые сломают код.

Вообще нужно понимать несколько уровней идеализма в тестах (по моей практике):
1. Тестов нет вообще
2. Есть немного тестов на самый важный функционал
<= Где-то здесь команды начинают внедрять CI/CD =>
3. Тестов больше, но из-за того, что кто-то в команде пишет больше тестов, кто-то меньше - покрыто примерно половина кода
4. Добавляется второй слой тестов, например, помимо юнит тестов, пишут еще приемочные тесты
5. Команда, пусть и не пишет 100% покрытия кода тестами, но старается покрывать тестами все бизнес-кейсы
6. Аналогичного покрытия тестами добиваются и на другом слое тестов (например, на приемочных)
<= Где-то здесь некоторые команды начинают писать отдельные тесты на фронт =>
7. Стремление к 100% покрытию кода юнит-тестами
8. Добавление мутационного тестирования
9. Совсем-совсем идеальные юнит-тесты, где тестируемый класс не завязан на другие классы

При этом нигде в рабочих проектах, я пунктов 7-8-9 не встречал вообще.

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

Answer 2

[dmitriy]

Когда вы тестируете метод А вашего класса, вы проверяете его логику а не логику других (замоканых методов), может быть ситуация когда ваш метод А работает по логике корректно, а вот другой метод Б другого класса используемый в тестируемом методе выдает ошибку, возникает вопрос нужно ли считать что ваш метода А работает неправильно из за упавшего метода Б ?

Comments

[Tokenchik]

Хороший пример, который как раз укладывается в пример того что я понимаю, если перевести в прикладной пример - это какой-то сервис, внутри которого есть http клиент, который во время тестов по тем или иным причинам не может сделать запрос и вернуть корректный результат, чтобы проверяемый класс смог работать с ними, в этом случае необходимо делать мок этого клиента и его метода который и занимается отдачей этого ответа, и в моке ответа клиента подсовываем наборы данных по 2-м ситуациям - ответ который мы считаем корректным чтобы убедиться что тестируемые класс работает, а вторая - ответ с ошибкой, чтобы проверить что тестируемый класс смог обработать ошибку, примерно так?

[dmitriy]

да, а ответ с ошибкой стоит эмулировать если у вас есть логика обработки этой ошибки

[dmitriy]

опять же у вас есть класс который вы мокаете, назовем его $this->currencyRateService->getRates();
сегодня вы получаете данные с http сервиса, завтра вы переведете получение данных из файла или из бд.
нужно ли вам каждый раз во время ваших тестов тестировать подключение к бд/файловой системе/внешнему сервису, нет, это задача других тестов

[Tokenchik]

dmitriy, а задача каких тестов проверять что данные из бд были получены именно в ожидаемом виде, переданы в какой-то сервис и он вернул правильно смапленную коллекцию из набора сущностей с правильными значениями? Этот момент не из головы, реальный кейс, когда необходимо проверять чтобы валюты соответствовали странам.
Со стороны тестировщиков есть уже автоматические тесты, которые проверяют апи метод, а со стороны бэкенда какие виды тестов должны быть?

[dmitriy]

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

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

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

Answer 3

[Александр]

Отрывок из книги.
Одной из важных особенностей unit-тестирования является тестирование в
изоляции. Unit (класс, функция или другой модуль) должен быть изолирован
от всего остального мира.Это будет гарантировать, что тест тестирует только
этот модуль. Тест может упасть только по двум причинам: неправильный тест
или неправильный код тестируемого модуля. Тестирование в изоляции даёт
нам эту простоту и быстродействие

Обычно зависимость - это интерфейс, который имеет несколько реализа-
ций. Использование реальных реализаций этого интерфейса во время unit-
тестирования - плохая идея, поскольку там могут проводиться те самые опера-
ции ввода-вывода, замедляющие тестирование и не дающие провести тести-
рование этого модуля в изоляции. Прогон unit-тестов должен быть быстр как
молния, поскольку запускаться они будут часто и важно, чтобы разработчик
запустив их не потерял фокус над кодом. Написал код - прогнал тесты, еще
написал код - прогнал тесты. Быстрые тесты позволят ему оставаться более
продуктивным, не позволяя отвлекаться. Решение в лоб задачи изоляции
класса от зависимостей - создание отдельной реализации этого интерфейса,
предназначенного просто для тестирования.

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

К примеру есть класс Заказ. Нам нужно его тестировать. У него есть зависимости: Налог и прочее. Класс налога может быть класс, который получает Значение по api. Так вот есть смысл при тестировании Заказа создать мок Налога

$tax = $this->createMock(Tax::class);
$tax->method('calculateTax')
->willReturn(0);

$newOrder = new Order($tax);

Дальше идут тесты класс Order. Они будут изолированные. Есть основной класс, который ты тестируешь. Для него ты Мок не создаешь. А вот для классов с зависимостями создаются Моки, но не всегда. Если класс зависимостей например содержит просто константы. То создавать Мок и дублировать код смысла нет