покрывать новые фичи тестами, и столкнулся с такой проблемой: тесты получаются иногда громоздкими. И по большей части они громозкие из-за подготовки теста, где создаются всякие моки и стабы и т.д.
Т.е. как мне кажется в том, что для каждого класса я пишу свои немного уникальные моки и стабы. Например в стабе бд я настраиваю только те таблицы, которые мне нужны.
Как подходить к написанию моков и стабов? Слышал, что их вроде пишут отдельно пишут (прям кладут в отдельную папочку проекта с тестами и т.д.). Подскажите пж, в какую сторону можно копнуть?
Я бы не советовал создавать отдельные компоненты для создания моков и стабов. Тогда чтение теста зачастую вызывает трудности у других разработчиков и теряется один из плюсов юнит тестирования - описание функционала тестом. Можно создавать общий метод для инициализации основных стабов внутри каждого теста- обычно так делаю.
Я не совсем понял) чуть позже вернусь с примером моего теста)
А, теперь понял. По сути я так и делаю. То есть все необходимое держу в самом классе. Инициализации основных стабов выношу в приватные методы, их и юзаю. Максимум - написал пару фабричных классов по паттерну Builder, чтобы легче было создавать основные Entity проекта.
По поводу плюсов - да, сразу видно, какие данные отвечают за данный функционал, которые ты тестишь. Но и минусы есть - тест становится нагроможден вот этой всей подготовкой. Это не усложняет ли понимание тестов?
Вроде норм. Я когда начинал погружаться в модульное тестирование, поначалу для написания тестов создавал базовые классы - тесты которые содержали базовую логику для стабов и фейков, в итоге люди которые смотрели эти тесты потом тратили больше времени для понимания работы базовых классов, чем написания самого теста )))
Понял, спасибо) Просто да, тестов пока мало. Нет четкого понимания как структурировать тесты, чтобы их в дальнейшем дешевле было поддерживать
Обсуждают сегодня