❓Писать ли тесты на том языке, на котором сделан продукт ❓

Этот вопрос все еще иногда мелькает в обсуждениях. И даже вызывает холивары🙂

Есть три обстоятельства, которые помогают найти нам ответы на этот вопрос:

1) Мобильная автоматизация уже отменила этот выбор де-факто, апиум умрет, у него нет выбора. Поэтому тут только Kotlin и Swift, и если вы работаете или планируете работать с мобилками - уже можно и нужно приучаться к одному языку со своим проектом. Но, что если вам не нужна мобилка или вы почему-то имеете аргументы в пользу appium?

2) Рынок труда. Заколебешься искать QA auto с чем-то, кроме питона, джавы или JS/TS. Почему? Ну, а) курсы и б) джуны пишут свой первый автотест в компании синьеров, которые тоже учили питон, джаву или JS/TS. И смотрят на них. Короче, замкнутый круг, и если у нас продукт на GO, Rust или даже очень распространенных PHP и C# - то экономически и менеджерски может быть выгодно тупо писать тесты на чем-то другом. Мы так и делали в PropellerAds: сервисы на Go и что-то на PHP, тесты - на Java. Но это именно менеджерское и экономическое решение, а не потому, что питон или джава созданы всевышним для автотестов.

3) Польза для компании, улучшение dev experience, итоговое качество продукта - на мой взгляд растет, если QA и разработчики буквально общаются на одном языке. Если QA ставит свой апрув на PR разработчика и наоборот. Именно QA инженер должен влезать в код разработчика, а не разработчик "якобы поможет нам с тестами". Чуете разницу? Аргументация "выберем язык бекенда, нам помогут написать автотест" - в большинстве случаев ложная, разработчику своих дел хватает. А вот "освоим язык и платформу своего продукта что бы глубоко разобраться как он работает" - крутая аргументация, у нее только один недостаток - QA инженеру приходится не сидеть на жопе ровно с питоном или джавой, а изучать постоянно что-то новое 😁

А вы как думаете?

Опять рубрика "Баг или Фича" в IDEA:

1) Имеем JUnit Extension, который кладет в context List<CategoryJson> :

final List<CategoryJson> result = new ArrayList<>();
           context.getStore(NAMESPACE).put(
                  context.getUniqueId(),
                  result
              );

2) Имеем желание прокинуть этот List<T> через ParameterResolver в виде массива в аргументы теста:

  @Override
  public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return parameterContext.getParameter().getType().isAssignableFrom(CategoryJson[].class);
  }

  @Override
  @SuppressWarnings("unchecked")
  public CategoryJson[] resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class)
        .stream()
        .toArray(CategoryJson[]::new);
  }

3) А теперь самое интересное 🙂 Этот код - работает, но IDEA его подсвечивает: Can be replaced with Collection.toArray(). Соглашаемся, и наш метод resolveParameter принимает вид:


1️⃣было :

    return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class)
        .stream()
        .toArray(CategoryJson[]::new);

2️⃣стало :

return (CategoryJson[]) extensionContext.getStore(NAMESPACE).get(extensionContext.getUniqueId(), List.class).toArray();

И тест с таким кодом не запускается, мы имеем ошибку:

java.lang.ClassCastException: class [Ljava.lang.Object; cannot be cast to class [...model.CategoryJson; ([Ljava.lang.Object; is in module java.base of loader 'bootstrap'; [...model.CategoryJson; is in unnamed module of loader 'app')

C точки зрения моего понимания - все ок, мы действительно потеряли Method Reference CategoryJson[]::new и теперь наш массив имеет тип Object[] (хотя под капотом там на самом деле CategoryJson[] 🥲), но, потеряли-то мы его просто согласившись через ALT + ENTER с подсказкой IDEA. При этом весь контекст (в виде type casting), казалось бы, есть - ну убери просто лишний stream(), зачем убирать CategoryJson[]::new ?

Ребят, если есть пара минут, пройдите, пожалуйста, опрос от нашего ДОДО-шного QA Mobile лида, на предмет - интересно ли вам что-то поизучать по специфике Mobile тестирования, быть может, сделаем что-то крутое по итогу 🙌

Предлагаю угадать целиком заголовок слайда с одного из online занятий Дмитрия. Или тему занятия. В качестве приза - экскурсия по офису Додо (Алматы, Москва или Питер, о дате и времени договоримся) и пиво за мой счет 🍺

Итак, определить справеделивого победителя предыдущего соревнования не удалось (а на кону - экскурсия в офис ДОДО в Мск / Спб / Алматы и пиво за мой счет после этого в баре), поэтому, я написал класс Konyagi. Там все, кто отметился в комментариях. Завтра в 15-00 по московскому времени будем разыгрывать в прямом эфире 🚀

А тем временем, у нас открыта вакансия Senior Backend QA 🚀- в самый высоконагруженный и важный для бизнеса сервис - MAPI (бэкенд нашего мобильного приложения Dodo Pizza).

MAPI написан на C#, и тесты там на нем же. Там много, много интеграционных тестов на эндпойнты и бизнес-сценарии (пишут их, в основном, разработчики), полноценное и точное по профилю покрытие нагрузочными тестами (пишут и поддерживают их ребята из команды Performance QA), и ранее в MAPI никогда не было выделенной роли QA инженера.

Что хотим?

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

Рассматриваем хороших инженеров и без опыта в C#, но готовых получить этот опыт у нас. Если интересно и есть вопросы - пишите в тред или в ЛС.

Апдейт, розыгрыш пива и экскурсии будет либо сегодня позже, либо в понедельник, сейчас не получается(

Итак, в 17.00 по Москве начнем в прямом эфире розыгрыш экскурсии и пива для коняг 😈

Го в google meet

Возникла идея 💡

У меня давно есть мысль: написать немного кода в Allure (переписать свой же PR по gRPC), и в Retrofit - создать SOAP Converter. Без подготовки, с нуля, с дебагом, запусками перезапусками, с юниттетстами и вот этим всем. Ниже будет опрос, интересно ли вам было бы посмотреть на такое в прямом эфире? Послушать что я делаю, как мыслю, как дебажу, как тестами покрываю? Может быть, вы даже не против немного донатить на такие трансляции?

Подозреваю, что среди моих подписчиков много QA. И хочется спросить у вас (да-да, у тебя, мой дорогой читатель 🫵):

Чем, на ваш взгляд, занимается ваш QA Director, он же QA Head, в общем, самый большой начальник с буквами QA в должности?

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


А может быть, вы даже не знаете, как выглядит и как зовут вашего хэда? 😁

Breaking News 🚀
Вы могли и не знать, но я уже почти 4 года состою в программном комитете Новосибирской конфы CodeFest🙂

Помогаю делать программу, отбирать доклады и собирать эту, по моему искреннему мнению, крутейшую IT-конференцию. Сейчас идет набор спикеров. Количество заявок растёт, и чем ближе дедлайн, тем сложнее попасть в программу – конкуренция высокая. Если есть тема, которой хочется поделиться – подавайте заявку сейчас. Буду рад видеть вас на сцене, а от себя обещаю выгрузить свой опыт в вашу подготовку доклада.

🍺 И, конечно же, обещаю выпить с вами пиво на after party 🍺

CodeFest в этом году имеет #15 - юбилейный! пройдет 31 мая — 1 июня 2025 в Новосибирске. Я там обязательно буду.

#Java #qaguru

Скриншотные тесты - неизбежная необходимость во многих проектах, особенно где есть всякие красивые графики и диаграммы в canvas. Проверяется это только скриншотными тестами, и если мы используем Selenide, то понадобиться еще какая-нибудь библиотека-сравнивалка.

Самая известная из них - ashot от Яндекса.

Тогда наш код может выглядеть примерно так:

assertFalse(
   new ImageDiffer().makeDiff(
       expectedImage,
       ImageIO.read(requireNonNull($("canvas[role='img']").screenshot()))
   ).hasDiff()
);

где ImageDiffer - класс из ashot, expectedImage - ожидаемое изображение, которое у вас где-то в ресурсах, завернутое в BufferedImage.

Этот код всем неплох (и даже прекрасно прячется внутрь PageObject), но у меня к нему есть вопросы:

1) В случае падения именно этого ассерта, нам нужен совершенно специфичный формат Allure Attachment:

Allure.addAttachment(
   "Screenshot diff",
   "application/vnd.allure.image.diff",
   objectMapper.writeValueAsString(screenDif)
);

2) Нам надо иметь возможность перезаписать expected изображения запустив тест со специальным флагом (например, у нас новый браузер и в нем canvas выглядит слегка по другому).

3) Задачи 1 и 2 хотелось бы делать где-то под капотом, что бы наш код тестов вообще ничего не знал об этих особенностях.

Все эти пункты можно изящно решить с помощью JUnit Extensions, и это один из практических примеров, которые я рассказываю на своем авторском курсе для java автоматизаторов, который стартует буквально на следующей неделе. Наши скриншотные тесты будут простыми, а все, что сложнее ассерта - будет жить в Extension.

Приходите послушать меня и Мишу Рубанова в 54 сериях, я гарантирую, что это будет интересно 🚀

Друзья, привет! Пара апдейтов о том где я, что я

- Скоро я запущу стримы по online опенсорс-контрибушену ✅
- Активно готовлю программу Codefest 15, выступлю на квартирнике по нагрузочному с Head of QA VK Мишей Шваркуновым (конечно же, ссылка туда 😁)
- Готовлю OKR QA функции в DODO на Q2, помогаю растить крутой (процессно и технически) QA-процесс в нашем втором по размеру, но не по значимости бизнесе - Drinkit ☕️;
- Вместе с ребятами же в DODO двигаем автоматизацию кучи рутины - и я не про тесты: Self-service по работе с нагрузочными тестами, автоматизация сбора тестового покрытия по PageObject-ам (ноу-хау, между прочим 🚀), автоматические карантины тестов и многое другое;
- Готовим вместе с Ирой Стяжкиной шок-контент - Android приложение niffler, и отдельный курс по всему, что с этим связано 🔥🔥🔥
- И все еще продолжаю вести самый крутой по наполнению программы (готов поставить деньги на это утверждение) курс по Java тестированию "Java Advanced 2.0"! ⬇️⬇️⬇️

Прямо завтра жду вас на открытом занятии в рамках моего авторского курса

- Познакомимся с программой курса и учебным проектом;
- Расскажу, что такое JUnit Extensions и как они помогают писать декларативные тесты;
- Вместе с вами в режиме онлайн напишем первый автотест, использующий JUnit extensions — покажу все шаги и объясню (почти) каждую деталь. Остальные детали - на курсе );
- На занятии отвечу на ваши вопросы, причем любые. Хоть про Page-Object-ы в DODO 😁

До 2 апреля на курс действует моя персональная скидка 13%. Скидка только для участников вот этого канала likeaduck.

🔗 Cкидку по этой ссылке. Актуальная до 2 апреля.

До встречи завтра в 20:00 (МСК) онлайн 🙌