Если не писать юнит-тесты, то...

Кажется, что в 2к24 рассуждать на тему важности модульных тестов — бессмысленная и бесперспективная затея. Так ли это?

Я попросил 5 Senior Java Developer и 5 QA-инженеров продолжить фразу «Если не писать юнит-тесты, то...», и вот что получилось:

Ответы разработчиков:
1. Ты сам себе насрешь за шиворот;
2. Сэкономишь кучу времени и нервов, но получишь пизды от тестлида;
3. Вносить любые изменения в код становится больно и опасно;
4. Ничего не гарантирует верную работу функционала;
5. Можно сэкономить кучу времени;

Ответы тестировщиков:
1. Не словить первые баги;
2. Нужно быть готовым тратить больше времени на локализацию дефектов;
3. Каждый раз будешь сидеть на пороховой бочке;
4. Возрастут некоторые риски по проекту, такие как расширение кодовой базы и внесение изменений, а также потянет за собой увеличение времени на разработку и тестирование, а также будет под вопросом цель — стабильный рост проекта, так как за эту цель по большей части отвечают юнит-тесты;
5. Тогда мы не знаем, работает ли наше приложение, как задумывалось, на этапе разработки, а также увеличиваем трудозатраты при дальнейшем рефакторинге или расширении кода, поскольку не можем быть уверены наверняка, что не сломали что-то работающее;

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

Короче, простора для срача еще предостаточно.

Ручник...

У меня одного при слове "ручник" возникает ассоциация с  недоразвитым, ни на что не способным пиздюком, посаженным  на цепь?

Постоянно слышу это слово от всех в адрес тестировщиков, которые не умеют в автоматизацию. Причем и от самих тестировщиков тоже. Уебищнее всего слышать фразу от какого-нибудь QA-лида на конференции, типа "я своим ручникам поставил задачу...". Не специалистам по обеспечению качества, не qa-инженерам, и даже не мануальным тестировщикам. Ну спасибо, что не тормозам! Даже если это и не так, непроизвольно складывается впечатление о ЧСВ с максимальным доминированием над прирученными хомяками.

Вы хоть раз видели, чтобы в вакансии было написано "мы ищем в команду сильного ручника"? Индустрия лет 15 шла от тестировщика к qa-инженеру, чтобы это звучало ебче, а тут, блять, ручник.

Никто не хочет быть ручником...

Мой доклад стал лучшим (по мнению зрителей) на конференции СИБИРЬ.JS 2024. Второе место, хотя доклад был не менее крутым, получил Дима Тучс с темой про CI/CD в QA.

В своем докладе я рассказывал про моки и параллелизацию в Playwright на примере web-игры, которую самостоятельно реализовал. Получил очень много положительных отзывов и от начинающих тестировщиков, и от qa-экспертов, что вдвойне приятно. Раскрывать сложную тему для людей с разным уровнем подготовки всегда трудно. По-видимому, у меня это получилось.

Всем огромное спасибо! Как появится запись в открытом доступе, выложу ее здесь 😊

Ситуация: вы освободили джуна джина, который в знак благодарности предлагает вам любую CLI утилиту, которая облегчила бы вашу работу/жизнь. Не обязательно она должна быть связана с QA, но если у вас есть запрос, связанный с тестированием, будет вдвойне круто узнать, что болит. Если запроса нет, то можно пофантазировать и написать дичь. Что бы вы попросили?

Начиная с версии 3.3 в Spring Boot была добавлена расширенная поддержка для Testcontainers с Artemis, как это было ранее сделано для PostgreSQL в 3.1.

С новой поддержкой можно легко настроить контейнер для Artemis и использовать его в ваших тестах:

@SpringBootTest
@Testcontainers
public class MyArtemisTests {

    @Container
    @ServiceConnection
    static ArtemisContainer artemisContainer = new ArtemisContainer("activemq-artemis:latest");

    @Test
    void contextLoads() {
    }
}

Это демо примерчик, и никто вам не мешает всю конфигурацию вынести в отдельный @TestConfiguration класс.

Расширенная поддержка Artemis позволяет разработчикам/тестировщикам сосредоточиться на написании тестов, а не на настройке окружения. Да и выглядит все очень лаконично.

Больше не обязательно ебаться с @DynamicPropertySource или ApplicationContextInitializer. В общем, заебись!

Буду выступать 17–18 октября в Санкт-Петербурге на Heisenbug Autumn 2024. В докладе расскажу про 7 смертных грехов тестирования. Приходите пообщаться, если будете на конференции!

До Heisenbug 2024 остался ровно месяц... Ждете?

Друзья из Ozon Tech 28-29 сентября проводят конференцию E-CODE, которая пройдет онлайн и оффлайн в Москве по адресу Ленинская Слобода, 26 с.15. Ребята подготовили насыщенную программу с интересными докладами. И да, конфа абсолютно бесплатная!

Получил приглашение на E-CODE от Ozon Tech, и, конечно же, приду завтра! Если кто-то тоже будет на конфе, подходите пообщаться!

P.S.: машинка - огонь! Мои дочери оценили, а жена свитер! Я довольствуюсь  коробкой 😄

Кто я такой...

Слайд с таким названием встречается примерно в каждом докладе на любой конфе. И как же, сука, бесит, когда человек, который в IT примерно с неолита, обладает четвертым даном по QA или разработке, умеет параллелить автотесты силой мысли, находит баги еще в идеях разработчиков, нахваливает себя 2-3 минуты, и потом, блять, выдает максимально посредственный доклад и по содержанию, и по подаче.

Я лично вообще не люблю рассказывать о себе, и стараюсь ограничиться одной фразой для приличия. Хотя по всем канонам самопрезентации такие слайды — это must have любого уважающего себя спикера. Но меня не покидает ощущение, что если ты выдаешь полную хуйню в докладе, люди про тебя забудут, еще даже не успев выйти из зала (или зума). И напротив, если доклад — заебись, то люди узнают про тебя всё, что захотят, самостоятельно, без ебучих слайдов. Да и инфу о спикере всегда можно почитать заранее.

Что вы думаете по этому поводу? Вам интересно слушать информацию о спикере до доклада?

Буду выступать 16 ноября на конференции Codetalks в Алматы с докладом, который называется "Пробуждение силы QA". Он будет про Playwright. Обещаю, будет эпично. Вот вам небольшой трейлер к докладу!

Clock - одна из самых интересных фич в Playwright последних минорных версий. Данное API появилось в версии 1.45.0. Эта штука позволяет управлять временем внутри браузера. Теперь можно без заморочек тестировать приложения, которые завязаны на даты, таймеры, таймауты и прочие моменты, связанные с течением времени.

Выглядит максимально просто. Конструкция ниже установит для браузера 1 января 2000 года:

await page.clock.setFixedTime(new Date('2000-01-01'));

Вызвав в консоли DevTools

new Date()

Вы получите именно эту дату - 2000-01-01.

Но, естественно, Clock не будет работать, например, в сервисах с синхронизацией времени через API. Если web периодически запрашивает текущее время с удаленного сервера (NTP или REST), Playwright не изменит данные, которые приходят с сервера с помощью Clock API. Для этого понадобятся моки. Тоже самое касается JWT, завязанных на время, или, например, время в БД. Если приложение делает запросы к БД, которая использует серверное время для вычислений, то изменить это время, конечно же, не получится. Браузер only.

​​Мой доклад про Бажка и Мока с конференции "Сибирь.js 2024" теперь в открытом доступе.

Продублировал на разных платформах, чтобы можно было посмотреть без vpn:
Youtube
VK Video
Rutube

Мой доклад "Пробуждение силы QA" с конференции Codetalks, которая прошла 16 ноября в Казахстане, Алматы. Спасибо большое организаторам за очень оперативный монтаж.

Посмотреть запись можно на разных платформах:
Youtube
VK Video
Rutube

👉 Оставить анонимный отзыв о докладе вы можете по ссылке

#видеозаписи

Рубрика #ТестоваяСреда возвращается! Прошедший Heisenbug завершался докладом с необычной подачей, а теперь публикацию видеозаписей начнём с этого доклада.

В нём фигурирует Playwright, но интересно может быть и тем, кто не пользуется этим инструментом.

YouTube | VK Видео

Скачать презентацию с сайта Heisenbug

Докинул еще одну позицию в заказ, чтобы доставка стала бесплатной. И тут вдруг...

Вы знали, как вставить изображение в камеру Android эмулятора?

Если вам нужно подставить, например, QR-код для тестирования, есть небольшой лайфхак. Он позволяет добавить кастомные изображения прямо в интерфейс камеры. Вот как это сделать:

1. Редактируем конфигурационный файл
Откройте файл Toren1BD.posters, который находится в папке Android SDK, с помощью любого текстового редактора. Пример:

vim /Users/{user}/Library/Android/sdk/emulator/resources/Toren1BD.posters 

2. Добавляем настройки для изображения
В конец файла добавьте следующий блок:

poster custom
size 1 1 
position 0.1 -0.1 -1.9
rotation 0 0 0
default 8_march.png

Этот код разместит изображение 8_march.png в центре экрана камеры

3. Копируем изображение
Поместите файл 8_march.png в ресурсы эмулятора. Например:

cp 8_march.png /Users/{user}/Library/Android/sdk/emulator/resources/8_march.png   

4. Перезапустите эмулятор

P.S.: прекрасные девушки, поздравляю с 8 марта! 🌷

Aqua все...

JetBrains объявила о завершении поддержки Aqua — специализированной IDE для автоматизации тестирования. Причина — низкий уровень адаптации продукта. А по-русски — никто не готов за это добро платить.

Несмотря на прекращение поддержки Aqua, её основные функции останутся доступны через плагин Test Automation, совместимый с IntelliJ IDEA Ultimate, PyCharm и WebStorm.

🤖 2025: Год ИИ в автоматизации тестирования
Согласно отчёту Testing in DevOps от mabl, 2025 год стал переломным моментом в применении искусственного интеллекта в QA:
– 55% компаний уже используют ИИ в разработке и тестировании
– Среди зрелых DevOps-команд этот показатель достигает 70%
– 46% команд ускорили релизы на 50% и более по сравнению с 2024 годом
– 38% организаций, ещё не внедривших ИИ, планируют инвестиции в AI-driven автоматизацию
– 62% увеличивают бюджеты на инструменты и автоматизацию, а 51% — на найм QA-специалистов

Однако остаются вызовы:
– Только 14% команд достигают покрытия тестами более 80%
– До 20% времени уходит на поддержку тестов

Согласно отчету, ИИ помогает решать следующие проблемы:
– Генерация и поддержка тестов на основе ИИ
– Анализ рисков и приоритизация тестирования
– Автоматическое выявление и исправление нестабильных тестов

ИИ открывает новые возможности для роста и переосмысления ролей в QA. Но фундаментальные практики качества все еще остаются ключевыми.

А вы используете ИИ в своей работе?

​​🚀 Spring Boot 3.5.0 — что нового?
22 мая вышел релиз Spring Boot 3.5.0 — стабильная версия с рядом полезных нововведений для разработчиков, QA и DevOps-инженеров.

Основные изменения:
– Улучшенное структурированное логирование
Добавлена возможность настройки формата и содержания логов, включая трассировки и идентификаторы запросов. Трассировки запросов, ID, поля логов — всё конфигурируется. Удобно для анализа flaky и нестабильных тестов. Отлично интегрируется с JSON-логерами и Kibana/Grafana.

– Поддержка SSL для сервисных подключений
Теперь можно настраивать SSL-соединения для внутренних сервисов, улучшая безопасность взаимодействия между компонентами. Интеграции с TestContainers и Docker Compose тоже обновились в SSL-конфигурации. Стали доступны аннотации @Ssl, @JksKeyStore, @JksTrustStore, @PemKeyStore и @PemTrustStore. Теперь проще эмулировать безопасные соединения в автотестах. Можно писать реальные HTTPS-тесты без головной боли

– Загрузка свойств из переменных окружения
Упрощена конфигурация приложений в различных средах за счёт прямой загрузки свойств из переменных окружения.

– AsyncTaskExecutor с пользовательским исполнителем
Появилась возможность использовать собственные исполнители задач для асинхронных операций, обеспечивая большую гибкость в управлении потоками. Тестирование асинхронных интеграций без awaitility? Нужно попробовать...

– Автоконфигурация для фоновой инициализации бинов
Ускорена загрузка приложения за счёт автоматической настройки фоновой инициализации компонентов. Тесты тоже станут быстрее. Думаю, особенно заметнее станет при большом контексте с JPA, Security, Kafka и т.д.

– Аннотации для регистрации фильтров и сервлетов
Добавлены новые аннотации, упрощающие регистрацию фильтров и сервлетов без необходимости ручной конфигурации. Если у вас низкоуровневое api и в тесте нужное реальное обращение по Http, наверное, эмулировать нестандартные статусы, заголовки, куки будет проще.

– TestRestTemplate теперь использует ту же настройку follow redirects, что и обычный RestTemplate. До Spring Boot 3.5 TestRestTemplate по умолчанию автоматически следовал за редиректами (302, 301), даже если RestTemplate этого не делал. Это хорошо для тестов, проверяющих поведение до редиректа