Интересный контент должен подъехать на следующей неделе - буду за круглым столом обсуждать обучение QA😈. Свою первую школу автоматизации внутри PropellerAds организовал 4 года назад, ещё до прихода в qa.guru. Мне определенно есть, что сказать )

Кстати, мы еще делаем небольшой QA митап в Москве - но, без моего присутсвия😔. 12 декабря в офисе Dodo Brands в Москве.

За меня там будет лидер гильдии Web QA Женя Иванченко.

В программе разговор о том, как командам быстрее передавать фичи бизнесу и писать эффективные ассерты в интеграционных тестах. Приходите, будет интересно! Ну и офис наш, в предновогоднюю пору, крутой 💔

Участвовать можно онлайн или оффлайн (пиццу есть точно удобнее оффлайн), регистрация по ссылке до 10 декабря 👉🏻 https://qa-dodo-spb.timepad.ru/event/2670046/

А почему не будет меня? Мы устраиваем съезд лидеров QA направлений DODO в Алмате ровно в эти же даты. Будем вживую прожаривать OKR-ы, родмапы и вот это все на 2024 год.

#Java #gradle #automation

Вчера один из моих студентов задал вопрос -

Добрый день! Кто может подсказать какой JDK 17 версии нужно поставить чтобы не было конфликтов и можно было использовать selenide 7? Если выбираю JDK 17 версии , то ловлю ошибку "Could not initialize class org.codehaus.groovy.reflection.ReflectionCache"

Ну и скрин с этой ошибкой.

Опыт не пропьешь - я сразу сказал, что, видимо, gradle в проекте / системе не той версии, которая нужна для Java 17 (это версии 7.6 и выше). Студент стал разбираться и - конец немного предсказуем - дело было действительно в старой версии gradle (6.7). Обновили и все заработало.

И тут у меня один вопрос - неужели невозможно, если уж вы делаете разбивки по версиям, которые совместимы с той или иной JDK, неужели совсем невозможно вывести понятное сообщение об ошибке - "Дружище, у тебя несовместимые версии". Как новичок должен разбираться в

Could not initialize class org.codehaus.groovy.reflection.ReflectionCache

?
У меня нет ответа.

#этоневажно

Об ачивке, формулировке, должности - SDET.
Что это такое? Что он должен уметь из того, что не должен уметь QA Automation Engineer?

Я глубоко убежден что эту формулировку придумали из двух соображений:

1) Потешить свое ЧСВ. Уж больно не охота называться "всего лишь QA". Как бы стоять в одном ряду с джуниором, закончившим курсы и прочитавшим пару книг. А я, мол, целый SDET, знаю про докер, CI/CD умею, написал свой собственный фреймворк для отправки HTTP запросов и обернул методы селенида / плэйрайта кучей своих очень необходимых оберток! Я не просто "QA" - который умеет написать тест из шагов, я целый SDET!

Это примерно как если бы условный fronted developer с какого-то момента начал называть себя Software Engineer In Browser. SEIB. Что я не просто там верстаю и джсоны парсить умею, я ого-го. Не правда ли звучит потешно - придумывать понтовую доллжность? Но SDET-ы, конечно, считают что это звучит гордо. Что им, наверное, за это надо платить больше, или что их больше зауважают "настоящие разработчики и инженеры"🙂

2) И второй аргумент - я не хочу ручного тестирования, я только пишу код. Этот аргумент тоже не выдерживает критики, т.к. любой код написанный кем либо - он не висит в воздухе. Вокруг него всегда есть что-то до и после. И если для написания теста (зафиксировать поведение системы) надо проверить что это поведение вообще соответствует ожидаемому руками - это не "стремно", а нужно. Если для написания теста надо разобраться, как поднять тестируемую систему в docker-compose и положить в нее тестовые данные - это просто надо уметь и мочь сделать.

Совершенно не важно, впишите вы себе в резюме эти 4 буквы или нет. Важно то - понимаете ли вы своя ЯП, понимаете ли вы - что такое DevOps практики, умеете вы сами работать с инфрой, скриптами на CI/CD, умеете ли вы сами поработать с обсервабилити, а не тупо смотреть на графики в графане, которые сделал кто-то до вас. Разберетесь вы с проблемами в вашем докере, или нет. Сможете ли принести Pull-Request в Аллюр, Селенид или любой другой опенсорс, когда найдете там баг. Сможете собрать свой образ браузера для Selenoid или понять, что не так с конфигом nginx, почему вы вдруг получаете ConnectionRefused. Сможете ли вы не писать свои фреймворки, а сделать так просто, как только можно. Сможете ли сделать простой DSL создания тестовых данных, будь то json или аннотации/декораторы над тестом. Это все умения Senior QA Automation - а 4 буковки еще ни разу не смогли мне объяснить - почему их надо величать именно так, а не иначе.

Не стремитесь повесить на себя такую ачивку, у самых крутых экспертов в их линкединах и резюме зачастую написано просто "QA", эксперта красят не 4 буквы SDET.

Маленькая новость выходного дня.

Сам забыл (и вспомнил благодаря рассылке в чате qa.guru), что сегодня последний день общедоступной скидки 10% на мой курс Advanced, которая прекрасно суммируется с моим промокодом. Итого, 15% скидка на курс, который я стартую уже в эту среду, 21 декабря. Залетайте смотреть кодовую базу, смотрите тесты, экстеншены и все-все все в репо. Именно этому будем три месяца учиться онлайн на лекциях со мной (в основном) и не только🚀. Кому интересно - welcome aboard!

А еще мы уже пишем учебное IOS приложение Niffler, заканчиваем с фигмой редизайна, и планируем писать Android приложение. Stay tuned!

Сегодня на собеседовании спросил у QA инженера, у которого в резюме питон и джава/котлин:

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

Что бы вы ответили, если владеете обоими языками?

#обучение #java #qaguru

А еще сегодня стартую 4 поток своего авторского курса Advanced. Занятие отрытое для всех, так что приходите, даже если не хотите учиться. Ну а если вдруг думаете - надо оно вам или нет - посмотрите на один из лучших дипломов 3 потока от Миши Нестерова - проект Rococo

Фронтенд (rococo-client) к нему написан нашей командой, а именно Ириной из OZON fintech, но, каждая другая строка кода, каждый микросервис, каждая строчка тестов, и все-все все в этом репозитории - написал Миша, и это и есть наш диплом.

Мы даем front, остальное делают студенты.

На 4-м потоке мы будем давать целых два frontend-а на выбор (REST и GraphQL, совершенно разные проекты), а все бэкенды и тесты будут писать студенты. Будет очень 🚀 интересно 🚀. Промокод в закрепе 😁

Все готово к стриму, жду через 39 минут 🎄

Кстати, не обошлось без интересного бага. Завтра расскажу.

А это мы с СЕО Dodo Engineering встретились за полезным делом перед пиццерией)

А еще сегодня маленький JUnit Extension, который дизэйблит тесты, если есть открытый issue (например, ваш тест нашел баг, и вы завели issue или ваш тест устарел, и вы завели issue на его актуализацию):

1) Создаем аннотацию

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(IssueExtension.class)
public @interface DisabledByIssue {
  String value();
}

Именно в ней будет id (номер) заведенного issue

2) Пишем Extension

public class IssueExtension implements ExecutionCondition {

  private static final OkHttpClient httpClient = new OkHttpClient.Builder().build();
  private static final Retrofit retrofit = new Retrofit.Builder()
      .client(httpClient)
      .baseUrl("https://api.github.com")
      .addConverterFactory(JacksonConverterFactory.create())
      .build();

  private final GhApi ghApi = retrofit.create(GhApi.class);

  @SneakyThrows
  @Override
  public ConditionEvaluationResult evaluateExecutionCondition(ExtensionContext context) {
    DisabledByIssue disabledByIssue = AnnotationSupport.findAnnotation(
        context.getRequiredTestMethod(),
        DisabledByIssue.class
    ).orElse(
        AnnotationSupport.findAnnotation(
            context.getRequiredTestClass(),
            DisabledByIssue.class
        ).orElse(null)
    );

    if (disabledByIssue != null) {
      JsonNode responseBody = ghApi.issue(
          "Bearer " + System.getenv("GH_TOKEN"),
          disabledByIssue.value()
      ).execute().body();

      return "open".equals(responseBody.get("state").asText())
          ? ConditionEvaluationResult.disabled("Disabled by issue #" + disabledByIssue.value())
          : ConditionEvaluationResult.enabled("Issue closed");
    }
    return ConditionEvaluationResult.enabled("Annotation not found");
  }
}

3) Ну и запрос в github для retrofit:

public interface GhApi {

  @GET("/repos/qa-guru/niffler/issues/{ISSUE_NUMBER}")
  @Headers({
      "Accept: application/vnd.github+json",
      "X-GitHub-Api-Version: 2022-11-28"
  })
  Call<JsonNode> issue(@Header("Authorization") String bearerToken,
                       @Path("ISSUE_NUMBER") String issueNumber);
}

Я глубоко убежден, что если тест начал падать, то на это должен быть issue (если, конечно, там не на 5 минут исправить ситуэйшн). А если уж мы создаем issue, давайте дизэйблить тесты, как Петербуржцы

Дорогие друзья, коллеги, я надеюсь вам так же было интересно в 2023 в этом канале, как мне самому - в дискуссиях с вами. В новом году будет кое-что действительно интересное от меня на поприще QA - я уже начинаю работать над действительно крутым проектом для всех нас. С новым годом!🎄

Куда я пропал в 2024? В отпуск) Стараюсь сейчас вообще не думать ни о работе, ни о лекциях, ни о конференциях, пока получается. Но отпуск закончится, и будет много о планах в Додо, планах в qa.guru и, конечно, технических постов. Stay tuned 🙌

Вышел из отпуска :harold-the-pain:
Провел собеседование (неудачно), узнал, что сегодня дедлайн по OKR на 1 квартал (они-то уже есть, но были не внесены в нужную эксельку). Узнал что у нас прямо сейчас все хотят открыть 5 QA вакансий:
- Mobile QA
- Team Lead QA
- Performance QA
- Web QA
- Железячный QA 🙂

Пообсуждали архитектуру большого проекта Kotlin тестов и наметили, куда ее рефакторить.

А еще пропустил обсуждение важного вопроса в слаке*:

Куда бежать в случае землетрясения в Алматинском офисе

Теперь надеюсь, что эти знания не пригодятся 🙂

#Java #Spring

Об обновлении зависимостей.

Обновил тут в одном из своих Spring пет-проектов одну зависимость.
Было 1.1.2, стало - 1.2.1. Поменял местами 2 цифры так сказать, что могло бы пойти не так?

У меня напрочь отвалился Oauth 2.0 code flow.

Запрос /oauth2/token? отдает 400 BAD REQUEST. И говорит вот такое понятное сообщение об ошибке - UNSUPPORTED_GRANT_TYPE. Как же так, спрашиваю сам себя? Ведь я не менял grant_type=authorization_code в своем запросе;
В коде спрингового сервиса даже в DEBUG логгировании нет никаких ошибок и стэктрейсов, потому что эта ошибка и не логгируется при выбрасывании.

Что делать?

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

Метод OAuth2EndpointUtils.getFormParameters раньше доставал из запроса и GET-параметры, и URL-encoded параметры, а теперь - только URL-encoded параметры. Как же так, почему раньше-то можно было? Иду в RFC Oauth 2.0 и вот ответ -

The client makes a request to the token endpoint by sending the
following parameters using the "application/x-www-form-urlencoded"

То есть, еще месяц назад реализация OAUTH 2.0 в spring-authorization-server не соответсвовала RFC, принимая GET параметры! Так же ей не соответсвовал и мой код, отправляя GET параметры. Начав бомбить о том "да как так одна циферка зависимости ломает мой прекрасный код!" закончил философским "ошибаются все, и не боги горшки спринговые обжигают".

Тут есть и еще один вопрос, а почему я вообще изначально не прочитал нормально RFC и отправлял GET-параметры?

Потому, что до получения странной ошибки я просто думал, что мне будет достаточно посмотреть воркшоп автора книги Spring Security in Action - и в нем тоже показана отправка простых GET параметров. А значит, ошибаются не только контрибьюторы Spring, но и даже авторы книг о Spring.

Мои выводы
- ошибайтесь на здоровье;
- но, любите дебаг;
- и гитблэймы;
- и чтение спецификаций и RFC