Продолжение первой части статьи «IoT там, где вы не ждали. Разработка и тестирование (часть 1)» не заставила себя долго ждать. На этот раз я расскажу, какая была архитектура проекта и на какие грабли мы наступили, когда начали тестировать наше решение.

Disclaimer: ни одна мусорка сильно не пострадала.

Как я уже рассказывал в прошлой части, при разработке IoT-проекта, протоколы взаимодействия с девайсами — вещь довольно нестабильная, и шансы потерять связь с тестовыми устройствами после обновления прошивки были довольно большие. Разработкой занималось несколько команд, и было жесткое требование — не терять возможность тестировать бизнес-слой приложения, даже если перепрошивка устройств переломает весь флоу работы с датчиками.



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

Каждый раз, когда натыкаюсь на новую статью про то, как использовать BDD-подход и как он улучшает жизнь разработки, тестирования и менеджмента — я хватаюсь за лицо. (А сейчас не знаю как быть. Не хватаюсь за лицо, а просто грущу). Впрочем, такие же ощущения могут вызывать задачи по написанию Selenium тестов. Захотелось поговорить об этом с теми, кто сталкивается с Selenium тестами и разрабатывает различные инструменты для удобной работы с ними.



Мы (Всеволод Брекелов и Дарья Манухина, программный комитет конференции Heisenbug) пообщались с Анной Чернышовой, разработчиком библиотеки Akita и нового инструмента Healenium (ее доклад про BDD), и Иваном Крутовым, разработчиком Selenoid. Иван занимается инфраструктурой для Selenium тестов не первый год (Один из его мастер классов). Обсудили:

• BDD подход в 2020;
• Selenium и его развитие;
• Карьерный рост;
• Машинное обучение и Selenium.

Продолжение интервью «Кому еще нужен Selenium? Использует ли кто BDD в 2020? Машинное обучение в Selenium»

В диалоге участвовали:

• Всеволод Брекелов и Дарья Манухина(программный комитет конференции Heisenbug);
• Анна Чернышова, разработчик библиотеки Akita и нового инструмента Healenium;
• Иван Крутов, разработчик Selenoid.

В конце статьи можно узнать вывод, которым делятся Иван и Анна, а именно ответ на вопрос: «Стоит ли изучать Selenium или выбрать что-то другое?». Помимо этого нам удалось поговорить про:

• Человека-маркировщика и узнать, кто он такой;
• Ценных сотрудников в компаниях;
• Инструментарий тестировщика;
• Инфраструктуру для Selenium тестов;
• Конкурентов Selenium.

Применением IoT в фитнес-трекерах, колонках, пылесосах уже никого не удивишь. Думали ли вы, что различные датчики можно установить в мусорные контейнеры и мусоровозы для контроля вывоза мусора? Звучит странно и вызывает вопрос: «А зачем?».

Анатолию Коровину случилось поработать на таком проекте, который они делали с нуля. А в этой статье разбор его доклада с конференции Heisenbug, где он подробно рассказал, почему нужно было делать «Умный мусоровоз» и как велись разработка и тестирование этого проекта.

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

Я десять лет тестирую и пишу код, а последние четыре года — тестирую доклады в программном комитете конференции Heisenbug. Сегодня расскажу о сквозных тестах, кросс-браузерности и ощущениях от использования Playwright версии 0.10.0.

Из конца в конец

Зачем нужны сквозные (end-to-end) тесты? Они управляют браузером и имитируют действия пользователя. Например, я описал пользовательские сценарии и хочу, чтобы они были проверены с каждой версией продукта. Проверять все сценарии для всех версий вручную — дороже и дольше, чем автоматикой.

Есть разные инструменты: Selenium, Puppeteer, Protractor, Cypress и другие. Две недели назад вышел новый инструмент — Playwright, над которым работал Андрей Лушников, разработчик Puppeteer. Эта библиотека полностью решает проблему написания кросс-браузерных тестов.

Совсем недавно вышла статья про новый инструмент Playwright, одним из авторов которого является Андрей Лушников. Нам выпала возможность пообщаться с Андреем и задать все вопросы, которые внимательные читатели написали в комментариях. Думаю, в этом лонгриде они смогут найти ответы. Немного спойлеров:

• Андрей рассказал историю развития Playwright и Puppeteer;
• ответил на вопросы про протоколы, которые используют для работы с браузерами;
• рассказал про сложности браузерных движков и планируемые интеграции Playwright.

Андрей Лушников приедет на конференцию Heisenbug, где и у вас будет возможность задать ему вопросы.

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



Под катом — видео и расшифровка доклада Артема Ерошенко из Qameta Software с конференции Heisenbug. Он представил несколько разработанных простых и элегантных решений, которые помогают команде Яндекс.Вертикалей оценивать покрытие тестов, написанных автоматизаторами тестирования. Артем расскажет, как можно быстро узнавать, что покрыто, как покрыто, какие тесты прошли, и мгновенно смотреть наглядные отчеты.

Amazon. Игры. Звучит необычно? Как тестировать продукт и для разработчиков, и для геймеров? Под катом — тестирование игрового движка Amazon Lumberyard, подходы как в ручном тестировании, так и в автоматизации, а также используемые на проекте инструменты.



Lumberyard — это кроссплатформенный игровой движок, на котором можно бесплатно создавать игры для большинства современных платформ: PC, Mac, iOS/Android, все приставки, в том числе очки виртуальной реальности. Он также довольно глубоко интегрирован с Amazon Web Services и сервисом игровых трансляций Twitch.

Под катом — видео и расшифровка доклада Артема Несиоловского с конференции Heisenbug.