Как правильно писать unit тесты?

Question

[xfg]

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

У меня возник этот вопрос, после изучения юнит-тестов в Yii фреймворке. LoginFormTest::testLoginNoUser() обращается к методу LoginForm::login(), который внутри себя вызывает LoginForm::getUser() и процесс выполнения выходит за рамки класса LoginForm в класс User. В итоге получается, что тестируются LoginForm::login(), LoginForm::getUser() и User::findByUsername(). Но почему. Ведь я не должен хотеть здесь тестировать работу метода User::findByUsername(), я хочу делать это в другом тесте.

Можно ли это назвать юнит-тестированием или это всё же интеграционное тестирование?
Сейчас же получается, что User::findByUsername() неявно тестируется в LoginFormTest, а также будет явно тестироваться в UserTest, это нормально? И если да, то нормально ли сваливать всё в одну директорию и юнит тесты и интеграционные? Где грань.

Answer 1

[He11ion]

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

Answer 2

[thyratr0n]

Непонятно, что вы хотели получить в ответ, ибо не задали четкого вопроса.

Во-первых, вы, конечно, "удачно" выбрали Yii первой версии в качестве примера. Эта фреймворка не очень приспособлена для изготовления "тестопригодного" кода, ибо содержит на всех стадиях функционирования большое количество "магии". Не верите? Попробуйте что-то наваять на базе CActiveRecord и запилить юнит-тесты. У вас получится что угодно, но не то, что надо.
Самый главный аспект юнит-тестирования состоит в том, что один тест (метод класса-теста) должен решать строго одну задачу, а не проверять в фоне целую подсистему.
На одном из своих проектов я решил эту проблему, написав целую свору заглушек.
Во-вторых, все зависит от задач. Грубо говоря, юнит-тесты проверяют код как есть. Следующий уровень тестов (не берусь его называть, ибо я их постоянно путаю) проверяет бизнес-сценарии. И самый высокий уровень проверяет все это дело в связке с внешними интерфейсами.
И в-третьих, один тест не должен включать код других тестов, ибо каждый тест должен быть изолирован, считая, что весь остальной код работает. Именно поэтому, когда вы пишете, например, тест для мелкой модельки, не нужно гонять работу с БД: считается, что вся подсистема взаимодействия с БД _работает_.

Да, и еще. Очень часто путают моки и стабы.
Стаб - это заглушка - код, который "глушит" выполнения другого. Цель заглушки - проверка того, _что_ возвращает объект в своей работе. В вашем случае нужен какой-то объект, который не позволит коду выполняться далее LoginForm::login(). Как это сделать? При статической типизации кода - никак. Нужна надстройка, которая будет динамически использовать данные объекты, чтобы их можно было заменить на стабы.
Мок - это надстройка над тестируемым объектом, целью которой является проверка того, _как_ работает объект внутри, именно поэтому моки всегда строятся на Reflection.

Comments

[xfg]

Прошу внимательнее. В качестве примера я выбрал Yii второй версии. Привел пример. И задал четкий вопрос. Вот он

> Можно ли это назвать юнит-тестированием или это всё же интеграционное тестирование?

И далее спросил. Критичен ли тот факт, что в процессе тестирования одного метода, неявно тестируются и некоторые другие методы системы. Я хотел выяснить нужно ли всегда в юнит-тестах мокать все зависимости или нет. Если нужно, тогда почему разработчики Yii посчитали по другому?

Я задал четкий вопрос, на который вы к сожалению дали ответ из которого ничего не понятно.

[thyratr0n]

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

Скажем так, если юнит-тест при провале какого-то шага не позволяет однозначно определить метод с ошибкой (без чтения трейсов и дебага), то это не юнит-тест.

На счет того, почему у разрабов Yii такой взгляд на тесты. Всяк кулик свое болото хвалит (с) Вот, и ответ. У каждого свои рамки и критерии.

И на ваш вопрос я ответил:
>> Самый главный аспект юнит-тестирования состоит в том, что один тест (метод класса-теста) должен решать строго одну задачу, а не проверять в фоне целую подсистему.

[xfg]

thyratr0n: спасибо, я примерно понял.

[hellboy1981]

>Цель заглушки - проверка того, _что_ возвращает объект в своей работе

В стабе мы обычно уже задаем а первом этапе A возвращаемое значение (файл - существует), а потом на последней стадии мы проверяем, вызван ли стаб и с какими параметрами.

Шпионы нам нужны когда: или нам интересно посмотреть *возвращаемый результат* _реальной функции_

Хотя никто не запрещает использовать шпиона, если нужно заглушить вызов без возвращаемого значения

Терминология приведена мной для `JavaScript`/`sinon.js

Не знаю, как она верна для C#/Java.

Answer 3

[matperez]

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

Пример:
В LoginForm можно выделить явную зависимость от чего-то вроде UserFinder, который может найти пользователя по email или login. Вместо него можно подсунуть некий объект возвращающий вполне конкретную модель пользователя.
Тестировать модель пользователя в этом тесте нам тоже не хочется, поэтому UserFinder должен вернуть не реальную модель User, а опять же некую заглушку, возвращающую наперед заданные данные.

Проще всего для создания заглушек использовать моки из phpunit. Через эту штуку так же можно мокать отдельный метод всего класса. К примеру можно сделать, что бы метод findUser в модели LoginForm сразу отдавал "правильного" пользователя и тем самым убрать из рассмотрения UserFinder.

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

Comments

[xfg]

Спасибо, я это все знаю. Мне интересно, в каких типах тестов вы тогда предлагаете проверять, что аутентификация действительно работает верно с настоящими данными правильными/неправильными логинами/паролями. В чистом юнит-тесте это проверить нельзя, остается либо интеграционый либо функциональный. Я хочу выяснить немного другое, грань, где лучше писать юнит-тесты, а где интеграционные. Я думаю, что писать на каждый тестируемый метод и юнит тест и интеграционный тест это слишком затратно по времени. И зачастую является бесполезной тратой времени. Ниже пример.

Я могу замокать LoginForm::getUser() и сделать чтобы он сразу отдавал правильные данные. Но я думаю, что от такого юнит-теста пользы нет, потому что, если замокать LoginForm::getUser(), то в методе LoginForm::login() по-сути и нечего проверять, так как логика его работы крайне проста. Я думаю разработчики Yii исходили примерно из таких же соображений. И поэтому написали здесь интеграционный тест. Просто потому, что юнит-тест здесь не имеет смысла.

Я расчитывал получить ответ, примерно следующего содержания, что в некоторых ситуациях лучше написать на тестируемый метод интеграционный тест, а в некоторых юнит тест, предварительно оценив ситуацию. И то, что User::findByUsername() будет тестироваться два раза в разных тестах - это не критично и вполне нормальная практика.

Вы действительно видите какой-либо смысл писать на LoginForm::login() чистый юнит-тест ?

[matperez]

xfg: Если вы в тесте LoginForm замокаете поиск пользователя, User::findByUsename() там тестироваться уже не будет, точно так же как какой-нибудь User::checkPassword(). Писать или не писать чистые юнит тесты зависит исключительно от вас самих, ну и от кода, который должен это позволять.

[xfg]

matperez: Ну я об этом и пишу, что замокав поиск пользователя, смысла от такого теста не будет, потому что логика метода LoginForm::login() очень проста. И думаю, что здесь нужно чувствовать грань, когда писать юнит-тесты, а когда интеграционные и в целом не разделять их на две разные группы.

[nonlux]

Для теста не должно быть важно сложная или простая логика зашита в проверяемом методе. Тест защищает код от от "плохих" изменений.
Допустим ваш товарищ завтра решит, что лучше при не удачном логине лучше возвращать null а не false.
Или FormLogin:validate будет по поводу и бес повода сыпать исключения, а они у вас в методе login не обрабатываются.
Тест с моками защитит вас от этого.
В целом мне больше нравится реализации BDD для php, связкой behat и phpspec
Спецификации phpspec заменяют unit tests
А сценарии behat заменяют инеграционые тесты
И перестаешь думать о том надо ли писать интеграционные или какие-либо еще тесты.

[xfg]

nonlux: Я почитал интернет на эту тему, все пишут как попало, точнее не все, большинство вообще никак не пишут.

[matperez]

Гляньте видео https://www.youtube.com/watch?v=DlgadZLOK-M мне кажется вам будет полезно. Вкратце: для своего кода нужно писать юнит тесты и писать код так, чтобы он мог быть покрыт именно юнит тестами. То, что вы мокаете какую-либо зависимость не означает, что тест становится интеграционным.
Чужой код тестировать вообще не нужно. Если вам нужно протестировать взаимодействие с чужим кодом - это уже территория интеграционных тестов.

Answer 4

[nonlux]

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

Я считаю в целом верно. Что бы эту решить проблему придумали дубли (вот гугл на русском показал).

Т.е если писать чистый юнит-тест для LoginForm, то оптимальным решением на мой взгляд заменить на "моки":
- YII:$app->:$app->user, который вернет для Yii::$app->user->login()false
- app\models\User , который вернет для User::findByUsername()null

К сожалению, с YII не работаю и поэтому более детальною реализацию подобного сейчас написать не могу.

Можно ли это назвать юнит-тестированием или это всё же интеграционное тестирование?
И если да, то нормально ли сваливать всё в одну директорию и юнит тесты и интеграционные? Где грань.

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

Если же писать сначала код, а потом его покрывать тестами они уже больше похожи на интеграционные, как вы говорите. Собственно так и есть в вашем примере.

Я лично для себя пришел к выводу что подобная теоретическая мишура мне мешает и я не выделяю тесты на такие категории. Для себя я выделяю тесты которые тестируют бизнес-логику приложения и тесты (спецификации) для кода.