Comments 11
Когда обнаруживаешь себя в поисках "самой лучшей тулы для генерации моков", то самое время задуматься - а может ты тесты пишешь не на том уровне на котором нужно? Потом расползаются килотонны файлов которые вербозно проверяют что тест точно повторяет логику кода и вызывает каждый из созданных моков... :)
Задача ребят – написать бизнес-логику и протестировать её.
вот в данных примерах честно говоря не очень много той "логики" для тестирования которой нужны моки. Что в тесте создания посылки делают например expect-ы для GetUser? Всё это код который в общем-то к задаче тестирования не относится. И такого кода в тесте получается 95%.
Вообще поскольку нынче модно писать "микросервисную архитектуру" (и вероятно вы так и делаете) - надо как-то перестраивать мозг и рассматривать свой микросервис как единицу для тестирования, а на более низкий уровень лазить только в исключительных случаях.
А можно с чуть меньшим пафосом давать непрошенные советы?
которые вербозно проверяют что тест точно повторяет логику кода
Любой тест проверяет логику кода - это его цель. И в моменте написания кода он может казаться избыточным, но когда приходит кто-то другой и корректирует эту логику, тест стреляет - и это его задача.
Всё это код который в общем-то к задаче тестирования не относится.
Всё верно, это не про задачу тестирования, а про сохранение логики кода спустя n правок.
надо как-то перестраивать мозг и рассматривать свой микросервис как единицу для тестирования
А ещё пора эволюционировать в киборгов, а то что всё как приматы.
В теории это, конечно, логично, но на практике тесты, которые покрывают слишком большой кусок логики, либо недостаточно детализированы, чтобы обнаружить мелкие ошибки, либо слишком громоздки. Парочка таких тоже должна существовать, но их одних не достаточно.
Юнит-тесты - это, безусловно, килотонны файлов. Но это килотонны маленьких файлов, которые просто читаются, запускаются и редактируются. А монстр, который основательно "тестирует микросервис как единицу", не продержится в реальном проекте больше двух спринтов - его снесут озверевшие разработчики.
Спасибо за статью.
Не указано, какие тесты используем? Unit или какие-то другие?
Mockery позволяет использовать тип Anything и это реально помогает некоторые параметры не принимать в тесте, если они не нужны для конкретного кейса, например context.
Кстати, если бы в методах был бы сквозной ctx (context.Context) как аргумент, вызов асинхронного метода был бы простой в тесте с отменой.
сам использую минмок на проекте, вот он простой в использовании как автомат калашникова. никаких проблем с ним нет. любой джун разберется. трогал уберовский - вообще не зашло
Минимок прикольный, но очень не хватает проверки на порядок вызова методов. Есть даже ишью с несколькими лайками на эту тему - https://github.com/gojuno/minimock/issues/130
Как будто тесты написаны таким образом, чтобы показать, что minimock самый лучший вариант. И это понятно, ведь автор статьи = автори minimock
В первом тесте (Несбывшиеся надежды) minimock лучше, что использует явный тип, но это скорее минус т.к. нельзя использовать mock.Anything или mock.MatchedBy. Например, удобно это использовать для context.Context т.к. редко нужно проверять какой context передается.
Во втором тесте (Двойная подстава) можно добавить в конце мока .Once(), тогда он упадет, если мы попытаемся вызвать его несколько раз.
В третьем тесте (Асинхронный тест-драйв), в случае mockery (про gomock не помню) не нужно прокидывать канал т.к. в сам mock есть finalizer, который проверить, были ли запущены ожидаемые вызовы
Позволю себе не согласиться с вами, кейсы я старался подбирать так чтобы показать отличия инструментов, а не склонить всех использовать минимок (такой цели у меня в принципе нет)
По поводу первого кейса, в минимок есть отдельный тип специально для контекста: minimock.AnyContext . В остальном я считаю что с статическими типами написание тестов становится в сотни раз легче, когда тебе не приходится вспоминать каждый раз какого типа аргументы функции, возвращаться к сигнатуре метода, ошибаться и потом кучу времени искать, в каком из ожиданий неправильный тип
По поводу второго кейса - да, можно Once, можно Times (о котором я пишу в выводе), но кейс сам о том как поведение по дефолту может сыграть злую шутку
По поводу третьего кейса, вы можете переписать этот кейс с finalazers и выложить поделившись ссылкой на гитхаб, я думаю это было бы очень полезно
У всех моков нет инструмента, с помощью которого можно проверить что контекст является потомком нужного нам контекста, либо его экземпляр.
Самый лучший мок на свете: разбираемся с инструментами для генерации моков в Go