Что меня мотивирует вести лекции по ночам (а делаю я это с 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
#maven #java
А еще я сегодня впервые в жизни словил какую-то неведомую хрень, добавив зависимость в pom.xml и нажав кнопку "скачать зависимости". Еще раз. Я начинал с Java 1.6 в 2009 году. Я доработал до Java 21 и 2023 года. И впервые словил по-настоящему неведомую ошибку с мавеном! Сегодня день, когда
А еще я сегодня впервые в жизни словил какую-то неведомую хрень, добавив зависимость в pom.xml и нажав кнопку "скачать зависимости". Еще раз. Я начинал с Java 1.6 в 2009 году. Я доработал до Java 21 и 2023 года. И впервые словил по-настоящему неведомую ошибку с мавеном! Сегодня день, когда
maven для меня стал похож на gradle - ведь там неведомые ошибки возникают в каждом втором проекте 🥲 Надеюсь, следующий такой день будет еще через 14 лет.😱9😁7💔5🤔2🙏1
#regression #testing #manual
Важный вопрос - если мы находим баг на регрессе - надо ли проверить, был ли он в предыдущей версии, которая на проде? Я считаю, что это первое, что необходимо проверить. Если баг был (а может и в пред-предыдущей версии, а может он там уже годами) - то это информация, которая говорит нам о том, что что-то не так с тестированием. Мы пропускали этот баг как минимум 1 раз (а может 101 раз). Надо написать на это тест. Может, это закрывается банальным юнит-тестом на три строки, может нужен e-2-e. А может просто нужен ручной тест-кейс, и не забывать его проверить на следующем регрессе. Может нужна галочка в чеклисте. Но энивэй - мы понимаем, что это свидетельство недостаточной надежности нашего релизного пайплайна.
Если же баг "новый" (то есть, его не было в предыдущей версии, мы его только занесли) - то у нас что-то не так с разработкой, мы плохо подумали об AC и DoD, может банально невнимательно написали код, что-то не учли. Да, тут тоже в итоге должен появиться тест или тест-кейс, но такой баг должен радовать QA инженера, который его нашел, а вот "старый" - должен огорчать.
У нас в DODO не везде есть практика разделения таких багов на "новый"/"старый", где-то баг - это просто "ща пофиксим и поедем в прод", никаких выводов из них не делается.
Я хочу это изменить.
А вы что думаете?
Важный вопрос - если мы находим баг на регрессе - надо ли проверить, был ли он в предыдущей версии, которая на проде? Я считаю, что это первое, что необходимо проверить. Если баг был (а может и в пред-предыдущей версии, а может он там уже годами) - то это информация, которая говорит нам о том, что что-то не так с тестированием. Мы пропускали этот баг как минимум 1 раз (а может 101 раз). Надо написать на это тест. Может, это закрывается банальным юнит-тестом на три строки, может нужен e-2-e. А может просто нужен ручной тест-кейс, и не забывать его проверить на следующем регрессе. Может нужна галочка в чеклисте. Но энивэй - мы понимаем, что это свидетельство недостаточной надежности нашего релизного пайплайна.
Если же баг "новый" (то есть, его не было в предыдущей версии, мы его только занесли) - то у нас что-то не так с разработкой, мы плохо подумали об AC и DoD, может банально невнимательно написали код, что-то не учли. Да, тут тоже в итоге должен появиться тест или тест-кейс, но такой баг должен радовать QA инженера, который его нашел, а вот "старый" - должен огорчать.
У нас в DODO не везде есть практика разделения таких багов на "новый"/"старый", где-то баг - это просто "ща пофиксим и поедем в прод", никаких выводов из них не делается.
Я хочу это изменить.
А вы что думаете?
👍28💯8
Ребята, не пропустите топовый контент завтра в рамках открытых занятий QA.GURU. Этот тот случай, когда другого такого эксперта, говорящего на русском языке, вы не найдете даже при большом желании🙂. Ну и подписывайтесь на Мишин канал, конечно же!
Telegram
QA.GURU
Насколько важно учитывать функции универсального доступа при тестировании?
❓ Будем разбираться на бесплатном открытом уроке «Еще три способа управлять телефоном, которые стоит учитывать при тестировании» вместе с Mobile Head в Dodo Engineering, Мишей Рубановым.…
❓ Будем разбираться на бесплатном открытом уроке «Еще три способа управлять телефоном, которые стоит учитывать при тестировании» вместе с Mobile Head в Dodo Engineering, Мишей Рубановым.…
❤8
#java #automation
Хозяке java-автоматизаторам на заметку:
Периодически вижу подобные вопросы (и подобный код) тут и там:
Я не могу найти ни одной причины “модельным” классам (точнее, объектам) не быть immutable, уж во всяком случае, в тестах.
А начиная с Java 16 у нас есть ключевое слово record (на самом деле уже с 14, но там это была preview feature). Если вы его еще совсем не использовали, то о том, что это такое, советую послушать Тагира Валеева.
Тот же самый класс без всякого Lombok может выглядеть так:
Да, иногда можно придумать (хотя, в действительности, с трудом) поводы менять состояние объекта, но для этого мы вправе написать метод внутри нашего рекорда:
И пользоваться новым объектом. Ну, все как в любимом нами иммутабельном классе String.
Собственно, в учебном проекте моего курса qa.guru advanced все модели как на бэкендах, так и в тестах существуют в виде record. Чего и вам всем желаю и рекомендую. Вы же не на java 8? Selenide вот требует 17 🙂
Периодически вижу подобные вопросы (и подобный код) тут и там:
Схема ответа:
{
"users": [ 0 ],
"groups": [ 0 ]
}И класс для его маппинга
@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
@JsonIgnoreProperties(ignoreUnknown = true)
public class UserDataRegisterModel {
private Integer type;
private String name;
private String data;
private List<Integer> users;
private List<Integer> groups;
}
Я не могу найти ни одной причины “модельным” классам (точнее, объектам) не быть immutable, уж во всяком случае, в тестах.
А начиная с Java 16 у нас есть ключевое слово record (на самом деле уже с 14, но там это была preview feature). Если вы его еще совсем не использовали, то о том, что это такое, советую послушать Тагира Валеева.
Тот же самый класс без всякого Lombok может выглядеть так:
public record UserDataRegisterModel (
Integer type,
String name,
String data,
List<Integer> users,
List<Integer> groups
) {}
Да, иногда можно придумать (хотя, в действительности, с трудом) поводы менять состояние объекта, но для этого мы вправе написать метод внутри нашего рекорда:
public UserDataRegisterModel addType(int type) {
return new UserDataRegisterModel(type, name, data, users, groups);
}И пользоваться новым объектом. Ну, все как в любимом нами иммутабельном классе String.
Собственно, в учебном проекте моего курса qa.guru advanced все модели как на бэкендах, так и в тестах существуют в виде record. Чего и вам всем желаю и рекомендую. Вы же не на java 8? Selenide вот требует 17 🙂
YouTube
Тагир Валеев — Java 17 для тех, кто в танке
Подробнее о фестивале TechTrain: https://jrg.su/YR8JKw
— —
Не успели передохнуть от перехода на Java 11, а уже вот-вот выйдет Java 17! Кошмар, куда столько Джав! У вас не было времени следить, что там интересного произошло в трёх или пяти последних версиях?…
— —
Не успели передохнуть от перехода на Java 11, а уже вот-вот выйдет Java 17! Кошмар, куда столько Джав! У вас не было времени следить, что там интересного произошло в трёх или пяти последних версиях?…
❤21👍5🔥5
Мелочь, а приятно. Тем интереснее, что будет с действительно новым приложением в 2024 😈