Кстати, вот еще опрос (думаю - стоит ли писать на эту тему пост, если не актуально, то и не буду🥲)
- Есть кто-то, кто прям по-настоящему пишет автотесты на Java для SOAP веб-сервисов? И если да, то что вы используете для генерации тела сообщения (body) и всего сообщения (envelope)?
Изначально вам, конечно, доступен wsdl тестируемого сервиса.
- Есть кто-то, кто прям по-настоящему пишет автотесты на Java для SOAP веб-сервисов? И если да, то что вы используете для генерации тела сообщения (body) и всего сообщения (envelope)?
Изначально вам, конечно, доступен wsdl тестируемого сервиса.
Что меня мотивирует вести лекции по ночам (а делаю я это с 23 до 1 ночи)? Вот что
🔥34❤20👍8🏆3😍1
Тестировщикам было бы лучше, если бы в Java не было вовсе примитивных типов данных.
Уверен, что большинство из моих читателей помнят про них.
Но в чем ценность этих примитивов в QA автоматизации?
Кто-то скажет, что это все должно работать быстрее, потому, что есть какой-то стек и куча, и первый вроде бы быстрый, и примитивы вроде бы в нем живут. В действительности это так, но только для аргументов методов и локальных переменных в методах, но ни в коем случае не для полей объектов. Я далек от мысли, что это может оказать хоть какое-нибудь реальное влияние на скорость наших тестов. А вот кое что с примитивами по-настоящему плохо для тестировщика.
Это значения по умолчанию для полей классов (class fields).
Представим себе endpoint, который отдает нам json примерно такого содержания:
Что будет, если наш бэкенд случайно вообще перестает возвращать нам attemptsCount в респонсе?
А будет вот что:
И Jackson, и Gson по умолчанию прекрасно десериализуют
Тест просто останется зеленым.
Что интересно, в Java с недавней поры есть record-ы которые дают строгий immutable объект с all-arg конструктором, а все поля - финальные. Но и тут нас ждет сюрприз - и Jackson, и Gson создаст инстанс record-а cо значением 0 по умолчанию! Вот этого ожидать вообще не приходится - сеттеров-то нет, а конструктор ждет 2-х аргументов. Но это факт.
Если заменить
Да, я знаю, что заставить тест падать можно и настройкой
Уверен, что большинство из моих читателей помнят про них.
Но в чем ценность этих примитивов в QA автоматизации?
Кто-то скажет, что это все должно работать быстрее, потому, что есть какой-то стек и куча, и первый вроде бы быстрый, и примитивы вроде бы в нем живут. В действительности это так, но только для аргументов методов и локальных переменных в методах, но ни в коем случае не для полей объектов. Я далек от мысли, что это может оказать хоть какое-нибудь реальное влияние на скорость наших тестов. А вот кое что с примитивами по-настоящему плохо для тестировщика.
Это значения по умолчанию для полей классов (class fields).
Представим себе endpoint, который отдает нам json примерно такого содержания:
{"username":”dima”, “attemptsCount” : 0}
И представим тест, который проверяет бизнес-логику того, что у какого-то там пользователя действительно ноль попыток:@Test* где Response классический data-класс с приватными полями, геттерами и сеттерами
void apiTest() {
Response resp = apiClient.request();
Assertions.assertEquals(0, resp.attemptsCount());
}
Что будет, если наш бэкенд случайно вообще перестает возвращать нам attemptsCount в респонсе?
А будет вот что:
И Jackson, и Gson по умолчанию прекрасно десериализуют
{"username":”dima”} в объект java класса с двумя полямиprivate String username;И в
private int attemptsCount;
attemmptsCount вам просто будет подставлен 0 - потому, что так работают примитивы, у них есть значения по-умолчанию, и для int это - ноль.Тест просто останется зеленым.
Что интересно, в Java с недавней поры есть record-ы которые дают строгий immutable объект с all-arg конструктором, а все поля - финальные. Но и тут нас ждет сюрприз - и Jackson, и Gson создаст инстанс record-а cо значением 0 по умолчанию! Вот этого ожидать вообще не приходится - сеттеров-то нет, а конструктор ждет 2-х аргументов. Но это факт.
Если заменить
int в нашем классе или record на Integer - то наш тест сразу и надежно начнет падать, т.к. null уж точно не равен нулю. Да, я знаю, что заставить тест падать можно и настройкой
ObjectMapper (или Gson) при его создании или аннотациями наподобие @JsonProperty(required = true), но, в конце концов, отказаться от примитивов в тестах для полей классов и рекордов - проще.Oracle
Primitive Data Types (The Java™ Tutorials >
Learning the Java Language > Language Basics)
Learning the Java Language > Language Basics)
This beginner Java tutorial describes fundamentals of programming in the Java programming language
👍26🔥10
Представим, что вы пришли на курсы разработки и/или AQA, где учебный проект - достаточно сложный: Микросервисы, разные RPC, профили, докер-недокер, CI/CD и прочее. Важно! Сделаем допущение, что вы в этом всем не эксперт. Что бы вы выбрали и почему:
Anonymous Poll
50%
Сначала пройти программу, понять учебный проект и в конце обучения сделать похожий Дипломный проект
53%
На первом же занятии получить заготовку Дипломного проекта и наполнять его смыслом с помощью домашек
🔥2✍1
Сегодня анонсирован 4 поток моего авторского курса Advanced. Если в этом чате есть кто-то, кто думал пойти - то в скором времени я опубликую свой личный промокод на небольшую, но приятную доп. скидку. А опрос выше - мои мысли, что сделать с дипломной работой для 4 потока )
Linkedin
💣Анонсируем 4 поток нашего мощнейшего курса по Java Advanced
Курс для тех, кто хочет прокачаться в автоматизации на Java, научиться…
Курс для тех, кто хочет прокачаться в автоматизации на Java, научиться…
💣Анонсируем 4 поток нашего мощнейшего курса по Java Advanced
Курс для тех, кто хочет прокачаться в автоматизации на Java, научиться настраивать кастомные / собственные шаблоны для тестов и отчетов, обучиться тестированию Android и iOS (требуется MacOS).…
Курс для тех, кто хочет прокачаться в автоматизации на Java, научиться настраивать кастомные / собственные шаблоны для тестов и отчетов, обучиться тестированию Android и iOS (требуется MacOS).…
🔥22
#JUnit5 #Java
ArgumentConverter - Why you are not Extension? (
Я не понимаю, почему он не является Extension-ом.
Не я один - есть issue в статусе waiting-for-interest.
Ведет он себя очень похоже на любой другой Extension;
Подключаем через
где
возвращаемый
Так вот, о чем я тут думаю? Что, если у нас есть enum с типами юзеров (допустим, “админ” и “просто” юзер) и мы хотим написать параметризованный тест против них, который
1) создаст юзера с полученным типом перед тестом;
2) и сделает что-то с ними после теста? (условно, в AfterEachCallback);
Начнем c энама:
Напишем тест:
И ArgumentConverter для него:
Пока все логично? По-моему, вполне.
Осталось решить вопрос - а можем ли мы что-то сделать после теста с этими юзерами (удалить из БД - просто как пример)?
В Extensions такой вопрос просто бы не стоял - мы бы сохранили этих юзеров в ExtensionContext, а ключом был бы test-case-id (допустим, аннотация
Но, у нас нет ExtensionContext внутри ArgumentConverter! 🫤
Надо городить какие-то свои “ТестКонтексты” в которые это сохранять, и вытаскивать оттуда. Но это не красиво и странно, потому что вы явно в других местах привыкнете использовать ExtensionContext.
В действительности, я не вижу ни одной технической причины отсутствия
Ну, и пойдемте, что-ли, напишем ребятам из JUnit, что было бы здорово, наконец, сделать их Extension-ом? Issue в начале поста🙌
ArgumentConverter - Why you are not Extension? (
Я не понимаю, почему он не является Extension-ом.
Не я один - есть issue в статусе waiting-for-interest.
Ведет он себя очень похоже на любой другой Extension;
Подключаем через
@ConvertWith вместо @ExtendWith, имплементируем интерфейс с простым методом:public Object convert(Object o, ParameterContext parameterContext)
где
Object o - Объект, что пришел к нам из датапровайдера;возвращаемый
Object - любой объект, который мы можем “создать” базируясь на полученном Object o, ну или прямо его и вернуть.Так вот, о чем я тут думаю? Что, если у нас есть enum с типами юзеров (допустим, “админ” и “просто” юзер) и мы хотим написать параметризованный тест против них, который
1) создаст юзера с полученным типом перед тестом;
2) и сделает что-то с ними после теста? (условно, в AfterEachCallback);
Начнем c энама:
enum UserType {
ADMIN("insert into ‘user’ (type...) values (admin...)"),
COMMON("insert into ‘user’ (type...) values (common...)");
public final String sql;
}Напишем тест:
@EnumSource(UserType.class)
@ParameterizedTest
void usersParameterizedTest(@ConvertWith(UserCreator.class) User createdUser) {
}
И ArgumentConverter для него:
class UserCreator implements ArgumentConverter {
@Override
public Object convert(Object o, ParameterContext parameterContext) throws ArgumentConversionException {
ResultSet result = executeScript(((UserType) o).sql); // create user
if (result.next()) {
return new User(result.getString("username"), (UserType) o);
} else throw new IllegalStateException();
}
}Пока все логично? По-моему, вполне.
Осталось решить вопрос - а можем ли мы что-то сделать после теста с этими юзерами (удалить из БД - просто как пример)?
В Extensions такой вопрос просто бы не стоял - мы бы сохранили этих юзеров в ExtensionContext, а ключом был бы test-case-id (допустим, аннотация
@AllureId над тестом), и имели бы доступ к ним в любых других Экстеншенах - в AfterEachCallback для нашей задачи. Но, у нас нет ExtensionContext внутри ArgumentConverter! 🫤
Надо городить какие-то свои “ТестКонтексты” в которые это сохранять, и вытаскивать оттуда. Но это не красиво и странно, потому что вы явно в других местах привыкнете использовать ExtensionContext.
В действительности, я не вижу ни одной технической причины отсутствия
ExtensionContext для ArgumentConverter (и до кучи и в ArgumentAggregator), а пока их там нет - предлагаю написать свой маленький дополнительный экстеншн, который дает нам возможность использовать ExtensionContext где угодно. Ну, и пойдемте, что-ли, напишем ребятам из JUnit, что было бы здорово, наконец, сделать их Extension-ом? Issue в начале поста🙌
GitHub
Create extension point for ArgumentConverter · Issue #853 · junit-team/junit5
As it stands argument converters need to be applied (with @ConvertWith) either to a custom annotation (at least it looks like that; couldn't make it work) or to the argument. When the former is...
👍8🔥1
Друзья, подъехал мой персональный промокод на 4-й поток Advanced курса автоматизации тестирования на Java.
Он дает скидку 5%, которая суммируется с остальными скидками на сайте –
DTUCHSPROMO5
Вся программа курса разработана мной, и включает в сжатом виде весь мой опыт в автоматизации тестирования и разработке на Java. Это максимально непохожий на "стандартные" курсы материал, на стыке с разработкой и devops. Лучше один раз увидеть 🙂
Он дает скидку 5%, которая суммируется с остальными скидками на сайте –
DTUCHSPROMO5
Вся программа курса разработана мной, и включает в сжатом виде весь мой опыт в автоматизации тестирования и разработке на Java. Это максимально непохожий на "стандартные" курсы материал, на стыке с разработкой и devops. Лучше один раз увидеть 🙂
qa.guru
Автоматизированное тестирование на Java для продвинутых | Онлайн-курс по написанию автотестов | QA.GURU
Продвинутый курс по автоматизации тестирования на Java. Курсы повышения квалификации на Java для тестировщиков уровня Middle и выше.
🔥33👍1
LikeaDuck🦆 pinned «Друзья, подъехал мой персональный промокод на 4-й поток Advanced курса автоматизации тестирования на Java. Он дает скидку 5%, которая суммируется с остальными скидками на сайте – DTUCHSPROMO5 Вся программа курса разработана мной, и включает в сжатом виде…»
#Testing #Management #Bugs
Пятничное: зачем вам (или вашему менеджеру) считать число багов?
У нас в DODO🍕 есть несколько команд, которые пилят приложение Dodo Pizza. Я даже затрудняюсь назвать точное число - но оно всегда где-то между 5 и 7. У каждой из них свой PO, свой QA, и свой бэклог с досочкой в тасктрекере. Какая-то команда работает над "лояльностью" (это кэшбеки, промоакции и т.д. в приложении), какая-то работает над меню, какая-то над всем что касается геолокации и адресной системы и так далее.
От чего тут грустно мне?
Я не знаю на какой из множества досок посмотреть, а что у нас с багами? Мы их находим? Мы их фиксируем? Мы о них знаем? Существуют дубли одних и тех же багов на разных досках. Есть еще огромная доска "баги из саппорта", и где и в чем она пересекается с командными - тоже очень расплывчатая материя.
А я хотел бы хорошо понимать, сколько и каких багов мы (QA) находим.
Зачем?
Я часто слышу мнение - "Это ужасно неправильно считать баги и мерять эффективность QA багами"!
Я же думаю, что это так же странно, как говорить что разработчика нельзя мерить числом закрытых задач и пулл-реквестов. Можно и нужно. Как с багами, так и с PR-ми разработчиков имеет значение их вес, их суть. И дело не в том, что если у Васи число "42" а у Пети число "23", то, Вася в 2 раза лучше. Может, вес 23-х багов (PR-ов) выше, чем тех 42-х. Но эти 2 цифры - в любом случае объективная информация, которую можно анализировать.
А вот расплывчатое "я работаю над культурой и процессом, я не какой-то там багхантер" анализировать много сложнее. Часто за этим, к сожалению, скрывается вовсе отсутствие пользы для бизнеса.
Итак, я предлагаю пристально обратить внимание на метрику DRE
Выражается она простой формулой:
Простой пример: я нашел десяток багов в приложении Dodo Pizza у себя на телефоне;
Если мы при этом перед релизом нашли 100 других багов, то наше качество
А если мы перед релизом нашли 20 других багов, то наше качество
А если мы вообще не нашли багов у себя, то
За этот коэффициент можно и нужно бороться, и тут даже не имеет никакого значения, что у вас с автоматизацией, Ci/CD и прочим.
Давайте радоваться каждому новому багу, найденому нами (а не пользователями) и считать их. А в DODO я рано или поздно добьюсь появления единого, а не распределенного источника правды о багах наших продуктов.
Пятничное: зачем вам (или вашему менеджеру) считать число багов?
У нас в DODO
От чего тут грустно мне?
Я не знаю на какой из множества досок посмотреть, а что у нас с багами? Мы их находим? Мы их фиксируем? Мы о них знаем? Существуют дубли одних и тех же багов на разных досках. Есть еще огромная доска "баги из саппорта", и где и в чем она пересекается с командными - тоже очень расплывчатая материя.
А я хотел бы хорошо понимать, сколько и каких багов мы (QA) находим.
Зачем?
Я часто слышу мнение - "Это ужасно неправильно считать баги и мерять эффективность QA багами"!
Я же думаю, что это так же странно, как говорить что разработчика нельзя мерить числом закрытых задач и пулл-реквестов. Можно и нужно. Как с багами, так и с PR-ми разработчиков имеет значение их вес, их суть. И дело не в том, что если у Васи число "42" а у Пети число "23", то, Вася в 2 раза лучше. Может, вес 23-х багов (PR-ов) выше, чем тех 42-х. Но эти 2 цифры - в любом случае объективная информация, которую можно анализировать.
А вот расплывчатое "я работаю над культурой и процессом, я не какой-то там багхантер" анализировать много сложнее. Часто за этим, к сожалению, скрывается вовсе отсутствие пользы для бизнеса.
Итак, я предлагаю пристально обратить внимание на метрику DRE
Выражается она простой формулой:
(Баги найденные командой) / (Баги найденные командой + Баги найденные пользователями).
Простой пример: я нашел десяток багов в приложении Dodo Pizza у себя на телефоне;
Если мы при этом перед релизом нашли 100 других багов, то наше качество
100/(100+10) = 0.9;А если мы перед релизом нашли 20 других багов, то наше качество
20/(20+10) = 0.66;А если мы вообще не нашли багов у себя, то
0/10 🥲За этот коэффициент можно и нужно бороться, и тут даже не имеет никакого значения, что у вас с автоматизацией, Ci/CD и прочим.
Давайте радоваться каждому новому багу, найденому нами (а не пользователями) и считать их. А в DODO я рано или поздно добьюсь появления единого, а не распределенного источника правды о багах наших продуктов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Testsigma Agentic Test Automation Tool
Defect Removal Efficiency: How To Calculate It For Test Automation
Learn what defect removal efficiency is and how to effectively calculate it for your test automation workflow, read now!
🔥31👾4❤2👍1
И я здесь. Будем сратегировать, в том числе, что же такое хороший QA. Попозже расскажу
❤6👍2
Forwarded from Стартап Продюсер⚡️
На этой неделе большая стратсессия IT Dodo Brands. Что важно — в оффлайне.
Широкий состав, единый контекст, дизрапт по всем направлениям.
В общем, делаем контент
Широкий состав, единый контекст, дизрапт по всем направлениям.
В общем, делаем контент
😁16
CFR. Он же - Сhange failure rate. Сколько процентов релизов от общего пришлось откатить и/или хотфиксить. Критически важен в мобильной разработке, с учетом специфики (долгая доставка хотфиксов до пользователей, невозможность принудительно заставить обновить аппку). Вопрос больше к Mobile QA / Mobile Developer в этом чате - а вы знаете, какой у вас CFR? Go обмениваться процентиками в комментах. Спойлер - у нас не очень.
🔥5
This media is not supported in your browser
VIEW IN TELEGRAM
Подъехали первые полезные инсайды (не побоюсь этого слова) со стратсессии от нашего СТО Паши Притчина. Must see!
😁37✍11🔥3👏3🤓3🤩2
Сегодня Dodo стратсессия - всё. 4 дня плотного брэйншторминга позади. 2024 обещает быть интересным, QA будем усиливать крутанами, делать крутанские тесты, отвязываться от приемочного тестирования... Но обо всем по-порядку, получится или нет все задуманное - буду писать сюда. Stay tuned 🍿
А, да и ещё нужен спец по куберу/кафке/джаве/графанам-прометеям-егерям в мою команду QA Performance. У команды недавно появился топовый техлид, будет супер-интересно. Вакансия будет открыта скоро.
По деньгам будет норм, а написать можно мне в лс)
А, да и ещё нужен спец по куберу/кафке/джаве/графанам-прометеям-егерям в мою команду QA Performance. У команды недавно появился топовый техлид, будет супер-интересно. Вакансия будет открыта скоро.
По деньгам будет норм, а написать можно мне в лс)
Telegram
Dmitrii Tuchs
Head of QA @ DODO Engineering | Teacher @ QA.GURU | Program Committee @ Codefest. My channel: https://t.iss.one/likeaduck
🔥23
#books #learning #Java
Тут недавно мой друг, коллега по QA-хэдству, крутой спец по автоматизации на Java, с которым мы несколько лет бок о бок работали на многих проектах (PropellerAds, Simscale и не только) - Миша Сидельников - написал книгу Let's Automate IT.
Я от всей души рекомендую ее к прочтению, многие из постулатов этой книги выведены, в том числе, из наших совместных попыток разобраться в так-себе-тестах, Миша - однозначно тот, к чьему мнению я сам всегда прислушиваюсь. Ну и цена вопроса - банановый раф или соевый латте 😁 Промокодик, опять же, на небольшую скидочку - TUCHS2023.
А на фото я, Миша и сами знаете кто в офисе Codeborne. Знаете же? 🙂
Тут недавно мой друг, коллега по QA-хэдству, крутой спец по автоматизации на Java, с которым мы несколько лет бок о бок работали на многих проектах (PropellerAds, Simscale и не только) - Миша Сидельников - написал книгу Let's Automate IT.
Я от всей души рекомендую ее к прочтению, многие из постулатов этой книги выведены, в том числе, из наших совместных попыток разобраться в так-себе-тестах, Миша - однозначно тот, к чьему мнению я сам всегда прислушиваюсь. Ну и цена вопроса - банановый раф или соевый латте 😁 Промокодик, опять же, на небольшую скидочку - TUCHS2023.
А на фото я, Миша и сами знаете кто в офисе Codeborne. Знаете же? 🙂
👍29❤17🤔2