Рубрика «интеграционное тестирование»

Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.

Полный цикл тестирования React-приложений. Доклад Авто.ру - 1

Алексей:
— Для начала надо немного рассказать, что такое Авто.ру. Это сайт по продаже машинок. Там есть поиск, личный кабинет, автосервисы, запчасти, отзывы, кабинеты дилеров и многое другое. Авто.ру — очень большой проект, очень много кода. Весь код мы пишем в большой монорепе, потому что это все перемешивается. Одни и те же люди делают схожие задачи, например, для мобильных и десктопа. Получается много кода, и монорепа нам жизненно необходима. Вопрос — как ее тестировать?

Читать полностью »

У нас был сервис на golang, отдельный топик kafka, clickhouse, gitlab-ci и падающий пайплайн, протухший ssh-ключ и вот это вот все, а еще сезон отпусков, жуткие ливни в городе, сломавшийся ноутбук, алерты по ночам, и горящий прод. Не то, чтобы это все было нужно для этой статьи, но раз показываешь типичные будни тестировщика, то иди в своем намерении до конца. Единственное, что меня беспокоило — это p0. В мире нет ничего более отчаянного, мрачного и подавленного, чем тестировщик, который пропустил это на прод. Но я знала, что довольно скоро я в это окунусь.
Читать полностью »

image

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

  • Что это такое
  • Его польза
  • Достоинства и недостатки
  • Как оно работает в Unity при использовании Test Runner
  • Как писать и выполнять юнит-тесты, которые будут проходить проверку

Примечание: в этом туториале предполагается, что вы знакомы с языком C# и основами разработки в Unity. Если вы новичок в Unity, то изучите сначала другие туториалы по этому движку.

Что такое юнит-тест (Unit Test)?

Прежде чем углубляться в код, важно получить чёткое понимание того, что такое юнит-тестирование. Если говорить просто, то юнит-тестирование — это тестирование… юнитов.

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

1. Обзор

С помощью Spring Data JPA можно легко создавать запросы к БД и тестировать их с помощью встроенной базы данных H2.

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

В этом руководстве мы покажем, как использовать Testcontainers для интеграционного тестирования со Spring Data JPA и базой данных PostgreSQL.

Читать полностью »

В релизном цикле сервиса есть критически важный период — с момента, когда новая версия подготовлена, до момента, когда она становится доступна пользователям. Действия команды между этими двумя контрольными точками должны быть единообразны от релиза к релизу и, по возможности, автоматизированы. В своём докладе Сергей Помазанов alberist описал процессы, которые следуют за каждым пул-реквестом в Яндекс.Такси.

— Добрый вечер! Меня зовут Сергей, я руководитель группы автоматизации в Яндекс.Такси. Если вкратце, основная задача нашей группы — минимизация времени, которое разработчики тратят на решение своих задач. Сюда входит все: от CI до процессов разработки и тестирования.

Что наша разработка делает, когда код написан?

Читать полностью »

Чтобы непрерывно улучшать большие клиентские интерфейсы, нужна мощная система автотестов. Разработчик Яндекса Дмитрий Андриянов dima117 кое-что про это знает — пару месяцев назад он поделился своим опытом на Я.Субботнике в Нижнем Новгороде.

— Сегодня я расскажу, как мы в Директе пишем модульные тесты на веб-интерфейс. Мы в целом посмотрим, чем тесты на интерфейс отличаются от других тестов. Рассмотрим два подхода к написанию тестов: с помощью Selenium и с помощью Headless-браузеров. И в конце покажу инструмент, который мы написали в Директе для запуска тестов в Headless Chrome.
Читать полностью »

С праздниками, друзья! Если вы не против научиться на каникулах чему-то новому, прочитайте лекцию Кирилла Борисова — разработчика систем авторизации Яндекса. Кирилл объясняет, как построить процесс тестирования Android-приложений, знакомит с современными инструментами и спецификой их использования.

— Прежде чем двинуться вперед, давайте устроим небольшой соцопрос. Кто из вас знает, что такое тесты? Кто пишет тесты? А кто знает, зачем он пишет тесты? Читать полностью »

Во вторник были озвучены результаты работы комиссии, расследовавшей причины аварии разгонного блока «Фрегат» со спутником «Метеор-М №2-1». Гадая о том, что случилось, мы пошли по верному следу, но все-таки не совсем правильно представили себе картину аварии. И Анатолий Зак, явно получивший инсайд, тоже не совсем точно пересказал сценарий произошедшего. А снабдив иллюстрациями выводы комиссии, мы, наконец, получим полное представление о ходе событий.

Окончательно разбираемся с градусами: причина аварии «Фрегата» - 1
Фото: Дмитрий Ловецкий/Associated Press
Читать полностью »

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

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

Читать полностью »

Многие программисты при выборе между интеграционным и юнит-тестом отдают предпочтение юнит-тесту (или, иными словами, модульному тесту). Некоторые считают интеграционные тесты антипаттерном, некоторые просто следуют модным тенденциям. Но давайте посмотрим, к чему это приводит. Для реализации юнит-теста mock-объекты навешиваются не только на внешние сервисы и хранилища данных, но и на классы, реализованные непосредственно внутри программы. При этом, если мокируемый класс используется в нескольких других классах, то и mock-объект будет содержаться в тестах на несколько классов. А поскольку тестируемое поведение принято задавать внутри теста (смотри given-when-then, arrange-act-assert, test builder), то поведение моки каждый раз заново задаётся в каждом тесте, и нарушается принцип DRY (хотя дублирования кода может и не быть). Кроме того, поведение класса декларируется в mock-объекте, но сама эта декларация не проверяется, поэтому со временем задекларированное в моке поведение может устареть и начать отличаться от реального поведения мокируемого класса. Это вызывает целый ряд сложностей:

1)Во-первых, при изменении функционала сложно вообще вспомнить, что помимо класса и тестов на него нужно изменить ещё и моки этого класса. Давайте рассмотрим цикл разработки в рамках TDD: «созданиеизменение тестов на функционал -> созданиеизменение функционала -> рефакторинг». Mock-объекты являются декларированием поведения класса и не имеют отношения ни к одной из этих трёх категорий (не являются тестами на функционал, несмотря на то, что в тестах используются, и уж тем более не являются самим функционалом). Таким образом, изменение mock-объектов классов, реализованных внутри программы, не укладывается в концепцию TDD.

2)Во-вторых, сложно найти все места мокирования этого класса. Я не встречал ни одного инструмента для этого. Тут можно или написать свой велосипед, или смотреть все места использования этого класса и отбирать те, где создаются моки. Но при неавтоматизированном поиске можно и ошибиться, проглядеть что-нибудь. Тут у вас, наверное возник вопрос: если проблема столь фундаментальна, как описывает автор, неужели никому не пришло в голову реализовать инструменты, упрощающие её решение? У меня есть гипотеза на этот счёт. Несколько лет назад я начал писать библиотеку, которая должна была собирать mock-объект так же, как IOC-контейнер собирает обычный класс, и автоматически создавать и прогонять тесты на поведение, описываемое в моках. Но затем я отказался от этой идеи, потому что нашёл более элегантное решение проблемы моков: просто не создавать эту проблему. Вероятно, по схожей причине специализированный инструмент для поиска моков конкретного класса или не реализован, или малоизвестен.

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

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

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо - 1
Читать полностью »