Comments 25
пожалуйста, пишите unit-тесты
Это сперва к менеджеру, пусть выделяет время. Скорее всего, или работодатель, или заказчик будут недовольны ростом затрат времени.
Я до сих пор в поисках статьи о том, что следует тестировать во фронтенде. Таких общих статей уже несколько видел, а с конкретными примерами не густо.
Привет. Как раз в книге по которой статейку написал, есть глава про "рост затрат времени". Очень рекомендую. Если кратко - растет время на разработку, но снижается время на поставку.
Ищешь, что тестировать unit-тестами на фронте? Могу запилить небольшую статью на эту тему. Подтверди, плиз, что я правильно понял.
Да, хотелось бы статью на эту тему. Скажем, есть у меня список книг, мой компонент запрашивает этот список через api, потом в цикле рисует компонент книги, где каждая книга содержит кнопку "добавить в корзину", иконку "добавить/добавлено в избранное", книга может иметь скидку, может участвовать ещё в какой-то акции. Все активные элементы передают событие куда-то наверх, мол, такая-то книга добавлена туда-то.
И вот что тут можно протестировать? Когда я пишу на vue v-on:click="$emit('add-to-cart')", то я уверен, что элемент сгенерирует это событие, мне нечего тут проверять. Если я пишу <button v-if="isAbleToAddToCart">Добавить в корзину</button>, то я уверен, что эта кнопка будет показана только если выполнилось какое-то условие, переключившее переменную в true. Получается, нужно лишь проверить, что это условие работает правильно. Но у меня зачастую такие вещи присылает сам сервер, или всё условие состоит из return this.inStockCount > 0, даже не знаю, стоит ли тратить время на то, чтобы задать два разных значения inStockCount и посмотреть, исчезнет ли кнопка. Конечно, исчезнет.
Вот это непонимание, как тестировать фронтенд, мешает мне в поиске рабты. Часто в вакансии требуется писать тесты, у меня на текущем месте работы их нет, поэтому я лишь знаю, как запустить тесты, как написать что-то на jest, но никогда их не писал. Получается, я не могу претендовать на вакансию, где нужно умение писать тесты. У меня нет умения.
Тривиальные вещи тестировать и не нужно.
Других не вижу. Может, у меня уже опыт набрался, что я всё вижу довольно тривиальным.
Вчера слушал разговор про отказ от TypeScript в некоторых проектах. Говорят, там профессионалы работают, они и так без ошибок пишут. Я TS ещё даже не распробовал, чтобы отказываться. Надеюсь, тесты не начнут выкидывать до того, как я с ними разберусь.
Как понимаю есть пара сложностей:
Непонятно, что покрывать unit-тестами. Кажется, что все методы довольно просты, и в их логике трудно совершить ошибку (допустить дефект).
Нет опыта разработки unit-тестов на front-end. На текущем проекте нет в этом необходимости.
Если разбирать проблемы по частям, то...
Покрывать unit-тестами на фронте нужно алгоритмы (или код с несколькими зависимостями), и то, что планируется к рефакторингу.
К примеру, на одном из моих проектов, ещё с этапа mvp "висит" часть агрегации данных (собственно, алгоритм), которые пришли с бэка, на фронте. Сейчас это проверяется функциональными UI-автотестами. А значит, проверка занимает больше времени, требует ресурсы на конфигурацию окружения, не такая стабильная как могла бы быть, и т.д. И, разумеется, никто это рефакторить не хочет: нет unit-тестов == код legacy == никто не хочет работать с legacy. Если кто-то бы захотел, то, как вариант, стоит покрыть код unit-тестами, и вперед - red-green-refactor.
Про отсутствие опыта. Ты же знаешь о jest. Нечего покрыть на текущем проекте из-за простоты дизайна? Не думаю, что стоит ждать подходящий проект, где можно будет научиться. Обычно, на таких проектах уже нужно уметь. Создай свой проект, под эти нужды. Начни это делать, и, со временем, количество проделанной работы точно приведет к качеству "умение в unit-тесты". Уверен, что у тебя получится.
У меня так плохо организовано рабочее время, что я не знаю, когда заниматься своими проектами. А если и есть на это время, то я лучше книжку почитаю. Конечно, можно себя заставить, но даже в своих проектах мне сложно придумать такой фронтенд, где были бы прямо Алгоритмы.
Хочется посмотреть на какие-нибудь примеры, чтобы понять, что конкретно другие люди тестируют, и как это делают. Пример доходчивее словесного описания абстракции. А уже поняв пример, можно обобщать и рассуждать обо всём остальном.
Книга случайно не дяди Боба, чистая архитектура?
Я вот сколько тестов видел... Не знаю, может озвучу не популярную идею и меня закидают тухлым кодом, но
Нужно тестировать библиотеки, общие компоненты (Типа ui-kit (кнопочки и т.п.) из которого строятся все странички), утилиты - короче, библиотечное или не UI-ое
А остальное лучше сразу end-to-end
IMHO
Вот количество e2e тестов в проектах моей компании, и побудило меня (в том числе) написать статью.
Абсолютное большинство проектов имеют общую черту - простой интерфейс пользователя, и сложные, временами запутанные, алгоритмы на сервисном слое.
Отсутствие unit-тестов не позволяет, соответственно, проводить интеграционное тестирование инкрементным методом - в модулях-то мы не уверены.
И сейчас, в основном, тестирование вынуждено концентрирует усилия на e2e проверках, и на интеграционном тестировании с подходом big bang. Приводит это к огромным тестовым наборам из e2e кейсов, а значит к очень дорогому и неповоротливому тестированию. Короче, тема для отдельного и нудного повествования. И закончится всё холиваром )
Обычно юнит-тесты разработчики пишут, а не QA. Они просто более в теме, как нужно протестировать то, что они только, что написали.
QA - пишет функциональные, UI тесты и т.п.
А что такое в определении "автоматизированный код"? Как-то цепляет и вызывает странное неприятное чувство.
Когда вижу "надёжный, читаемый, поддерживаемый" так и хочется добавить "выберите два из трёх", хоть это и не в тему здесь.
Я бы упомянул где-нибудь слово "независимый", ведь это реально важное свойство теста (у вас это, наверное, подразумевается в "консистентный")
Автоматизированный код... неудачно подобрал сокращение, спасибо. Имеется ввиду код для задач автоматизации.
Да, Вы правы. Независимость сама по себе не нужна - только для обеспечения качества консистентности. Для этого тест быть независимым от окружения, состояния тестируемого объекта, и от других тестов.
Нам бы в команду такого автоматизатора как автор.
Если после исполнения тестового метода вам нужно "откатывать" состояние, значит вы разрабатываете интеграционный тест. Вам ведь не это было нужно?
Всё-таки понятие unit тестирования немного размылось в связи с активным использованием testcontainers. В некоторых случаях мне надо поднять в контейнере базу или что-то ещё для теста.
Я с Вами не согласен. Test Containers нужны для интеграционного тестирования. Для unit-тестов лучше не прибегать к внешним зависимостям.
Однако они всё-таки позиционируют себя как "Unit tests with real dependencies". Да и по своей сути это гораздо ближе к unit-тестам, чем к интеграционным, т.к. никаких зависимостей с остальной частью системы тут нет.
Допустим, у меня есть пакет в котором логика работы с базой. Моки тут абсолютно бесполезны. Я поднимаю эту самую базу, прогоняю тесты и убиваю базу.
Понимаю, но тесты с реальными зависимостями теряют такие нужные (для unit-тестов) качества как консистентность и скорость исполнения. Исходя из этого, их уже нельзя считать вполне unit-тестами.
Почему в приведенном примере моки бесполезны? Потому что нужно проверить именно взаимодействие с БД? Тогда это по определению интеграционный тест. Ну, или тест совместимости (Interoperability).
В любом случае - замечательно, что такие тесты у Вас есть. Пусть они как угодно называются - главное, что Вы думаете о качестве продукта )
Один из моих коллег-автоматизаторов упомянул, что к нему обращаются разработчики с вопросом: "А как написать unit-тест?".
Наверно прозвучит не слишком вежливо, но почему разработчики у Вас обращаются не к более опытным коллегам своего профиля, а к инженерам по автоматизации тестирования?
Любой более-менее опытный разработчик с лёгкостью объяснит, как писать юнит-тесты, да и легко подскажет, какие стоит покрыть сценарии. Никаких секретных навыков QA для этого не требуется.
Про unit-тесты кратко