ThreadQA | Олег Пендрак

Автоматизация тестирования в идеальном мире: — пишем автотесты до релиза — спокойно деплоим — спим без тревоги Автоматизация тестирования в реальном мире: 1. Выпускаем релиз. 2. Ловим баг в проде. 3. Получаем сообщение: «Срочно починить!» 4. Чиним 5. На ретро слышим сакральную фразу: «Надо обязательно покрыть это автотестом» И так пополняется коллекция автотестов, каждый из которых хранит память о чьей-то бессонной ночи, горячем фиксе и сообщении в рабочем чате: «Кто это вообще пропустил?» 🧐 Самое забавное, что многие автотесты появляются не потому, что команда заранее всё предусмотрела, а потому что прод уже преподал очередной дорогостоящий урок Прод — лучший автор тест-кейсов, правда, очень дорогой

✍️ МОЙ ПУТЬ l ПРОДОЛЖЕНИЕ ЧАСТИ 4 После тестовых заданий меня позвали на финал с техническими директорами, мы обсудили мой бэкграунд и то, чем мне хочется заниматься А ещё через день рекрутер вдруг спрашивает, есть ли у меня другие офферы, и я даже не сразу врубился к чему это, пока друг не сказал, что меня поздравляет и мне явно готовят оффер Когда дошло до цифр, зарплата оказалась в три раза выше той, что я получал раньше. Я реально не верил, что столько вообще платят, а мой московский друг только посмеялся и сказал, что это обычная рыночная история Забавное было то, что в первый же мой рабочий день Mail переименовали в VK, и я наконец-то начал заниматься тем, о чём мечтал Самым непривычным было то, что на задачу могли спокойно дать неделю, а я по старой памяти продолжал делать всё за час😁 Я погружался в ios и android автоматизацию, работу с симуляторами, разбирался с CICD инфраструктурой и просто кайфовал, ещё и катался в командировки в московский офис и на корпоративы За три года я дорос до руководителя команды, ушёл больше в техническое развитие и инфраструктуру, выступил на конференции Heisenbug, и это была прямо моя золотая пора и прайм эра Вот так иногда одно случайное письмо, которое ты чуть не удалил, способно полностью развернуть всю твою карьеру и жизнь... На 100 👨‍💻 выпускаю заключительную часть Предыдущая часть — https://t.me/c/3706754029/69

Выгорал ли я за пять лет и как с этим справлялся Раньше мне казалось, что выгорание прилетает от самой работы, мол, слишком много задач, слишком сложно, слишком долго сидишь в коде А потом до меня дошло, что дело вообще не в работе как таковой, а в том, что в этот момент проседают все остальные сферы жизни Где-то ты неделями не виделся с друзьями, где-то в солнечный выходной сел доделывать задачу вместо того чтобы просто выйти погулять, где-то месяцами не выбирался никуда дальше маршрута дом-качалка-дом Вот из этого перекоса всё и растёт. Когда вся жизнь схлопывается в один только рабочий чат, любая нагрузка начинает восприниматься как невыносимая Хотя по факту дело не в количестве тикетов, а в том, что тебе банально нечем восстановиться и некуда переключиться Отдельная больная тема — это гонка за идеальным результатом и премией. Я сам через это прошёл, когда упахивался в надежде, что меня заметят, повысят или дадут какую-то награду А по факту премия очень часто зависит не от того, как ты пахал, а от настроения топа, который в моменте просто решил порезать бюджет, и всё, твои переработки никто даже не вспомнит И вот это стоит принять пораньше, чтобы не убиваться зря. Компании в большинстве своём довольно спокойно относятся к тому, кто и как выкладывается, и уж точно никто не будет ценить твоё здоровье больше, чем ты сам Можно годами жечь себя ради абстрактного повышения, а в итоге получить только усталость и пустоту внутри Поэтому для себя я понял простую штуку: работать нужно хорошо, но не ценой всего остального Я специально слежу за тем, чтобы в жизни хватало места на друзей, на спорт, на прогулки и на банальное ничегонеделание без чувства вины Чем больше я выхожу из дома, куда-то езжу и меняю картинку перед глазами, тем меньше меня накрывает та самая тяжесть от работы Отдельно топлю за поездки и путешествия, даже если это просто вылазка на выходные в соседний город Смена обстановки перезагружает голову лучше любого отпуска в кровати, и после таких вылазок я возвращаюсь к задачам с реальным желанием, а не с ощущением, что снова тащу мешок в гору Так что если чувствуете, что подгораете, посмотрите не на работу, а на всё, что вокруг неё Скорее всего, где-то там и найдётся тот самый перекос, который надо выровнять, и тогда работа снова станет просто работой, а не источником вечного напряжения Делитесь в комментариях как у вас дела с темой выгорания, интересно почитать ваши истории👇

✍️ МОЙ ПУТЬ l ЧАСТЬ 4 Письмо, которое я сначала отправил в спам 2021 год. После увольнения из компании Softline я выдохнул и неделю просто отдыхал, и тут мне на почту приходит сообщение от corp.mail.ru. Я на автомате решил, что это какие-то мошенники, и закинул письмо в спам, даже не открывая Через пару дней любопытство всё же победило, я залез посмотреть и увидел вполне нормальное письмо с вопросом, согласен ли я на обработку персональных данных, чтобы со мной мог связаться рекрутер Я нажал согласен скорее ради интереса, а уже на следующий день мне написал живой человек из найма Сначала меня звали на ручного тестировщика, и я был в лёгком шоке, что меня в принципе зовут в такую крупную компанию. Я честно сказал, что мне ближе автоматизация, и тогда мне предложили вакансию по автоматизации мобилок на ios и android в проекте myTarget, это агрегатор рекламы в вк Терять мне было нечего, опыта в мобилках ноль, и я был почти уверен, что прилетит отказ, поэтому пошёл туда вообще без мандража Собес с руководителем оказался максимально человеческим, мы много смеялись, обсуждали автотесты без воды, кидались мемами, и я прямо почувствовал, что хочу работать именно в такой лайтовой атмосфере с молодым тимлидом В конце он дал мне тестовое, написать пару автотестов на демо-приложение. Я с огромным интересом полез разбираться, поставил Android Studio, ковырял эмуляторы, а котлин для меня тогда был вообще тёмным лесом В итоге я двое суток не вылезал из всего этого, написал несколько тестов и отправил на проверку Пост получился очень длинным, поэтому давайте наберем 80 ❤️ для актива и я выложу продолжение 4 части

Работа над новым курсом идет полным ходом👨‍💻 Не вылезаю из-за компа уже несколько дней и если честно очень кайфую от процесса и качества того, что уже сделано Очень рад, что на самом деле получается самый лучший и сильный курс из всех, что я делал сам или видел у других Работаем🤝

Как мы убили 200 строк костылей одним JUnit Extension Приходит недавно приятель и говорит: написал самописный soft assert (чтобы тест собирал все ошибки и падал только в конце) Штука полезная, но он прокидывал экземпляр этого ассерта параметром ВООБЩЕ ВЕЗДЕ — в каждый метод, степ и хелпер В итоге в коде хаос, проверки теряются, читать это больно Идеальное решение здесь — JUnit Extensions У теста есть жизненный цикл. Вместо того, чтобы таскать объект руками по всему проекту, мы элегантно в него встраиваемся: 👉 Перед тестом (beforeEach) инициализируем ассерт и кладём в ThreadLocal (чтобы был доступен откуда угодно в рамках потока) 👉 В конце теста (afterEach) автоматически вызываем assertAll() и подчищаем память Скелет расширения выглядит так:

public class SoftAssertExtension implements BeforeEachCallback, AfterEachCallback {
    private static final ThreadLocal<SoftAssertions> STORAGE = new ThreadLocal<>();
    
    @Override
    public void beforeEach(ExtensionContext context) {
        STORAGE.set(new SoftAssertions()); 
    }
    
    public static SoftAssertions get() {
        return STORAGE.get(); // Достаём без параметров!
    }
    
    @Override
    public void afterEach(ExtensionContext context) {
        try {
            STORAGE.get().assertAll(); // Авто-проверка
        } finally {
            STORAGE.remove(); // Авто-очистка
        }
    }
}

А в самом тесте теперь абсолютная чистота:

@ExtendWith(SoftAssertExtension.class)
class OrderTest {
    @Test
    void checkOrder() {
        var soft = SoftAssertExtension.get();
        soft.assertThat(order.getStatus()).isEqualTo("PAID");
        soft.assertThat(order.getSum()).isEqualTo(1000);
        // assertAll вызовется сам в конце теста
    }
}

Весь бардак схлопнулся в одно маленькое расширение. Оно работает в фоне, само наводит порядок с контекстом и убирает грязь из кода Мораль: сильный автоматизатор не лепит костыли, а смотрит, умеет ли фреймворк решать задачу из коробки У JUnit, REST Assured и Selenide под капотом лежат бриллианты — нужно просто не лениться туда заглядывать

✍️ МОЙ ПУТЬ l ЧАСТЬ 3 Наверное это будет один из самых жёстких постов, потому что речь про работу, на которой меня хотели уволить почти каждый день 2021 год. Проработав в аналитике около семи месяцев, я уволился и снова пошёл штурмовать собесы на автоматизатора В этот раз в трудовой уже был хоть какой-то официальный опыт, так что меня стали пускать дальше скрининга и звать на технические собеседования Дальше опять пошла серия отказов, я слил четыре или пять собесов подряд из-за нехватки технической насмотренности, плюс по привычке называл ту же зарплату, что и в аналитике. Но в один момент подвернулся очередной собес в Softline, на который я шёл уже максимально на расслабоне Завалил я там буквально половину вопросов и был уверен, что это снова мимо. Единственное, что сделал иначе, это назвал зарплату в два раза выше прежней, потому что уже понимал, что снова получу отказ и терять нечего А через неделю мне звонят и говорят, что готовы делать оффер и спрашивают, когда я смогу выйти Тут надо честно сказать, каким я был на тот момент специалистом. Это был абсолютно зелёный джун, который не понимал даже разницы между private и public, а меня закинули единственным автоматизатором в компанию, где не было ни наставника, ни даже ручных тестировщиков

Руководитель попался очень строгий и требовательный, а его любимая фраза звучала примерно так: либо сделаешь до завтра, либо прощаемся

Спросить совета было не у кого, поэтому приходилось перерабатывать и изучать тонны новой информации по джаве за считаные часы, лишь бы не вылететь Забавно то, что именно там я дико прокачал ООП и техническую базу по джаве. Но атмосфера была такая, что каждый вечер перед сном я думал только о том, что завтра всё повторится по новой, и однажды просто взял и уволился спустя пять месяцев Понятно, что многое зависит от команды и проекта, и мне тут скорее не повезло. Но на самом деле этот стресс дал мне такой буст, что без него моё развитие растянулось бы года на полтора, так что в итоге я даже благодарен тому опыту Для себя я сделал вывод, что не каждая тяжёлая работа это однозначно плохо, иногда именно она за пару месяцев лепит из тебя нормального спеца На 80 👨‍💻 по традиции сажусь писать новую часть

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

✍️ МОЙ ПУТЬ l ЧАСТЬ 2 2020 год. После той самой практики я загорелся идеей стать автоматизатором и пошёл искать работу, но реальность довольно быстро и довольно жёстко спустила меня на землю Я реально думал, что раз мне нравится и что-то уже получается, то меня без проблем возьмут хотя бы джуном. На деле же оказалось, что без коммерческого опыта ты не нужен примерно никому, и это был неприятный для меня сюрприз Я откликался вообще на все компании в Перми, какие только находил, и отовсюду прилетал один и тот же вежливый отказ Через какое-то время стало совсем понятно, что в автоматизацию меня прямо сейчас никто не возьмёт, как бы мне этого ни хотелось. В любом случае мне нужен был хоть какой то коммерческий опыт, поэтому я решил зайти в айти с другой стороны и устроился бизнес-аналитиком в компанию Greendata, причём в офис Первая работа. Работа была совсем не про код, я рисовал там разные BPMN-схемы для банков, много общался с заказчиками, разбирался в их хотелках и переводил всё это в понятные и описанные процессы Поначалу мне даже было любопытно, потому что задача погружала в то, как вообще устроен бизнес изнутри и как рождаются требования к продукту Сейчас, оглядываясь назад, я понимаю, что эта работа дала мне куда больше, чем казалось на тот момент Я впервые попал в настоящую айтишную компанию и просто впитывал атмосферу, нахватался местного сленга, поработал с реальными базами данных, привык к рабочим созвонам и живому общению с командой. Это был мой первый опыт именно внутри индустрии, и он оказался полезнее, чем я думал Правда, не успел я толком влиться в коллектив, как накрыл ковид и всех разом разогнали по удалёнке. График у меня был с одиннадцати утра до восьми вечера, и он мне совсем не заходил, потому что весь день надо было сидеть на месте и оперативно разгребать тикеты из хелпдеска, решая проблемы заказчиков Чем дольше я там работал, тем чаще ловил себя на мысли, что это вообще не моё Мне не хотелось целый день обрабатывать обращения и согласовывать процессы, меня по-прежнему тянуло обратно к коду и автотестам, к тому, от чего я кайфовал ещё на практике Я проработал так около семи месяцев, набрался опыта, но внутреннее ощущение, что я занимаюсь не тем, никуда не уходило Главная мысль тут такая, что первая работа далеко не всегда про то, чтобы остаться там навсегда и построить там всю карьеру. Иногда она нужна просто чтобы зайти в индустрию, осмотреться, набить базовый опыт и понять, чем ты на самом деле не хочешь заниматься, что тоже очень ценно 80 👨‍💻 ускоряют написание и выход 3 части)

Как зайти в IT с нуля из другой профессии? Сегодня хочу показать вам историю моего ученика Петра, он обучался у меня в формате личного наставничества после изучения курсов До перехода в IT он аж 15 лет работал юристом, то есть в совершенно другой сфере. Но в один момент Петя захотел сменить направление и пойти в более техническую профессию 2.5 месяца мы разбирали все теоретические нюансы, решали практические задачи, закрывали пробелы по темам, которые нужны на собеседованиях и в работе, готовились к техническим интервью, приводили в порядок подачу опыта и понимание рынка Была проделана качественная личная работа, после которой Петр смог полноценно перейти из юриспруденции в IT Сразу после обучения он прошел 10 собеседований, получил 3 оффера и в итоге выбрал работу AQA На данный момент Петя работает в автоматизации уже 1,5 года и смог вырасти до senior-грейда, кайф Тот частый случай, когда курсы и личное обучение позволяют сэкономить месяцы, а иногда и годы самостоятельного изучения профессии, а также помогают обойти сотни ошибок, которые допускают как новички, так и опытные сотрудники Отзыв Петра можете увидеть выше🤝

Ребят, сейчас активно доделываю новый курс по автоматизации тестирования на Java «Java QA Automation 2026 — с нуля до Middle» Пройдите, пожалуйста, короткий опрос, чтобы я мог еще больше повысить качество и пользу от нового продукта https://forms.gle/5w6pEjqPd2ZcUwHN9 Всем спасибо🤝

✍️ МОЙ ПУТЬ l ЧАСТЬ 1 На самом деле вся моя история в автоматизации началась максимально случайно и без какого-либо плана Тогда я только начинал учиться в ВШЭ на бизнес-информатике, и если честно, вплоть до третьего курса вообще очень слабо представлял, кем хочу стать после выпуска 2020 год. 3 курс. На третьем курсе подошло время производственной практики, и я пошёл в компанию AlternativaGames, раньше они выпускали игру «Танки Онлайн» И вот там мне предложили попробовать писать автотесты, хотя я на тот момент ничего про это не знал и шёл в полную неизвестность И тогда меня прям сразу затянуло. Помню, как быстро пролетало время, когда я садился за задачу и начинал ковырять код... я мог просидеть несколько часов и даже не заметить, как рабочий день подошел к концу В то время я впервые поймал то самое ощущение, когда тебе реально нравится то, чем ты занимаешься, когда не приходится заставлять себя это делать через силу, для меня это был кайф Сама практика была рассчитана на две недели, и по задумке студент должен был не спеша вникать и потихоньку делать. А я на изи закрыл всё за два дня, причём не потому что хотел поскорее отделаться, а потому что мне было дико интересно и я просто не мог остановиться В итоге по отчёту я получил свои честные 10/10 и впервые почувствовал, что у меня по-настоящему получается Именно в тот момент до меня окончательно дошло, чем мне хочется заниматься дальше. Никакого великого плана и красивой стратегии не было, я просто наткнулся на случайную задачу на практике, попробовал и понял, что нашёл своё После этого я решил развиваться в автоматизации, пусть даже медленно и по чуть-чуть, но в эту сторону Иногда карьера начинается вообще без всякого сценария и громких решений, а с какой-то мелочи, которую тебе случайно подкинули И тогда я понял, что в жизни очень важно заниматься именно тем, что тебе реально нравится От чего у тебя горят глаза, о чем ты думаешь только что проснувшись утром и засыпая ночью, именно из такого и может вырасти дело всей жизни Накидайте 70 👨‍💻 для быстрого выхода второй части)

Чем вообще занимается Tech Lead QA Automation? В личку часто прилетает подобный вопрос: «Олег, а как вообще выглядят твои будни? Что ты там делаешь на позиции техлида в СберЗдоровье?» Если коротко — я ведущий инженер, и активно взаимодействую сразу с пятью командами Иногда ребята кидают код на ревью, иногда приходят за советом по архитектуре, спрашивают, как лучше спроектировать тест и где зарыты подводные камни И на самом деле мне это реально в кайф Самое крутое в этой рутине — видеть, как растут люди. Вот ты месяц назад сидел с человеком, разбирал сложную таску. А сегодня он не только сам щёлкает такие задачи как орешки, но уже и джунов подтягивает Сидишь и думаешь, что не зря потратил время и терпел его где-то глупые вопросы. Собственно, ради таких моментов я когда-то и начал делиться знаниями в чате и ютуб канале Но техлид — это далеко не только ревью и менторство Самое интересное начинается там, где автотесты упираются в инфраструктуру. И тут мы работаем в плотной связке с нашим DevOps, у меня на проекта девушка-девопс просто машина Она здорово вывозит меня по всей местной кухне, Kubernetes, поды, GitLab CI, гигантские YAML-конфиги и вот это всё Это идеальная командная работа: я приношу экспертизу по тестам, она — по инфре. Вместе мы за день собираем то, на что поодиночке я бы убил неделю Работа сапёром: свежий кейс из практики Недавно была интересная задачка: нужно было встроить запуск API-тестов прямо в релизный пайплайн. Звучит как задачка на пару часов и не более Начинаешь детальнее копать, разбираться, а там легаси монолитное и куча микросервисов Помимо моих тестов на Java, там крутятся чужие юнит-тесты на PHP, которые ждут отработки соседних пайплайнов Забудешь какую нибудь env переменную добавить — похороны Я провозился с этим недели две. И самой большой проблемой была даже не логика, а то, что эту штуку нельзя запустить и проверить локально Релизный пайплайн — это супер-секьюрная зона с кучей защит, куда мне доступы никто не даст В итоге ты пишешь сложный код почти вслепую:

Запушил коммит 👉 ждёшь пока завершатся соседние пайплайны 👉 ждешь пока прогонятся юнит тесты и соберется стенд 👉 ждешь пока дело дойдет до моих новых тестов 👉 смотришь где упало

Приходится предугадывать нюансы на пять шагов вперёд, запускать часть sh скриптов локально, чтобы проверить правильность синтаксиса и в случае чего закладывать фолбэки Но для меня это и есть настоящая инженерия — написать сложный код так, чтобы он завёлся там, где права на ошибку почти нет В итоге мы всё сделали, хотя и не с первого раза, но всё поехало как по маслу И вот такие головоломки, когда непонятно с какой стороны подступиться и нужно собрать пазл из разных технологий, я люблю больше всего Вот так и выглядят мои будни: ревью, помощь ребятам, инфраструктурные квесты и вечный движ. И знаете, я уже столько лет в профессии, а на работу до сих пор иду с искренним интересом Походу, это и есть тот самый главный признак, что ты на своём месте

Как Allure-отчёт отличает джуна от крепкого мидла Утро, ты открываешь результаты ночного прогона и видишь красный тест Проваливаешься внутрь, а там голый стектрейс и лаконичное: expected 200 but was 500. И всё, спасибо за информацию, очень полезно Дальше начинается квест: а что мы отправляли? с какими данными? на каком стенде? это баг бэка или тест кривой? В итоге ты лезешь в IDE, запускаешь всё локально и тратишь полдня на воспроизведение того, что нормальный отчёт подсказал бы за две минуты Идея простая: хороший отчёт должен отвечать на вопрос «почему упало» САМ, без похода в код. Это не просто раскрашенная статистика для менеджеров, это ваш главный инструмент диагностики. Чем больше полезных артефактов вы туда кладёте, тем быстрее команда чинит баги, и тем реже флаки-тесты превращаются в белый шум Что мастхэв прикрутить в Allure 👇 1️⃣ Для API-тестов В отчёте обязательно должен лежать готовый cURL-запрос. Чтобы ты нажал одну кнопку «скопировать», вставил в терминал и сразу повторил запрос руками Рядом кладём полные тела Request и Response, заголовки и статус-код. 90% проблем с API становятся очевидными ровно в ту секунду, когда ты видишь реальное тело ответа, а не абстрактную ошибку 500 2️⃣ Для UI-тестов Базовый гигиенический минимум — скриншот на момент падения. Он моментально показывает причину: перекрывший кнопку поп-ап, поехавшую вёрстку или слетевшую авторизацию Плюс супер полезно прикладывать консольные логи браузера. Поверьте, очень часто тест падает из-за невидимых глазу JS-ошибок на странице, а вы думаете, что локатор сломался 3️⃣ Performance-логи (скрытый гем) Штука, которую многие игнорируют, а она реально спасает. Особенно при таймаутах и флаки-тестах. По логам сети сразу видно: это тест «не дождался» элемента, или просто тестовый стенд тупит и грузит скрипт 15 секунд 4️⃣ Контекст окружения Где мы упали? Dev или Stage? Какая ветка? Какая версия билда или baseUrl? А для UI — какой браузер и версия драйвера? Одинаковое падение на разных стендах — это две абсолютно разные истории, без этой инфы вы просто гадаете на кофейной гуще Если собрать всё это вместе (cURL, скрины, логи, контекст) — ваш Allure превращается из бесячего «красного крестика» в полноценное досье на падение Вы перестаёте тратить время на расследования и начинаете реально фиксить проблемы🤝

30 🔧 собрали за 15 минут, я вас понял😁 Пошел писать первую часть🤝

Ребят, хочу внести больше разнообразия в контент в блоге Есть желание рассказать вам свою историю пути: как пришел в IT и с чего начинал, в каких компаниях работал, как я туда попал, мои ошибки и как пришел к тому, что имею сейчас Если вам интересно, прожмите 30🔧

Добавил новые реакции под постами Спасибо всем, кто проголосовал и накидывал варианты, нехило бустанули) Накидайте — 👨‍💻 🫡 🔧

Вопрос от подписчика: «Какая правильная архитектура API тестов» Раскладывай код не по названию, а по тому, насколько он переиспользуемый Чем шире используется, тем дальше от теста живёт. Чем уже и специфичнее, тем ближе 1️⃣Пакет api Тут живёт всё про общение с сервисом по HTTP и больше ничего К примеру класс OrderApiClient дёргает ручки заказов, AuthApiClient отвечает за авторизацию и токены Внутри пакета, можно сделать пакет dto, который хранит модели запросов и ответов. Здесь нет проверок и нет бизнес логики, только отправили запрос и вернули ответ 2️⃣Пакет asserts Переиспользуемые проверки, которые нужны во многих тестах OrderAssertions проверяет статус заказа и поля ответа, CommonAssertions проверяет код ответа и общую структуру контракта. Эти проверки повторяются из теста в тест, поэтому им тут и место 3️⃣Пакет utils Совсем общие штуки, не привязанные к продукту DateUtils для работы с датами, RandomDataUrils для генерации тестовых данных, JsonUtils для парсинга. Такой код спокойно переедет в другой проект без изменений 4️⃣Пакет helpers Уже про твой проект, но переиспользуемая подготовка UserHelper создаёт типового тестового пользователя, RequestBuilder собирает стандартный запрос к промежуточному сервису с одинаковой информацией. Они знают про предметную область, но не привязаны к одному тесту Про твой случай с подготовкой ожидаемых данных Тут соглашусь с лидом. Когда логика ожидаемого результата завязана на конкретный тест, его тоглы и его алгоритм, ей место в приватных методах этого теста Вынесешь в общий класс, и он быстро превратится в свалку условий под каждый частный случай Спроси себя, сколько тестов это используют Если много и независимо от продукта, это utils. Если много, но про твой проект, это helpers или asserts. Если просто отправка http запроса, это пакет api. Если логика только для одного теста, то приватный метод внутри тестового класса Не пытайся сразу построить идеальную архитектуру, она вырастет из практики Разнеси api, steps, asserts, utils и helpers по смыслу, специфичное держи рядом с тестом, а общее выноси наружу, когда видишь, что одно и то же повторяется в трёх местах

Сегодня сделаю 1-2 уровень бустов для блога Можете, кстати, проголосовать за канал, у кого есть премиум: https://t.me/boost?c=3706754029 Скидывайте в комментариях премиум эмодзи, выберу 1-2 самых прикольных и будем ставить ее под постам👇

TODO позже доделаю... В коде автотеста:

@Test
public void shouldReturnCorrectPrice() {
    // TODO: Временно закомментировал, падает только на CI
    // FIXME: Разобраться после релиза
    // Раскомментировать через 2 недели!!!
    // Не забыть!!!
    
    // assertEquals(expectedResult, actualResult);

    assertTrue(true);
}

Проходит время Сначала проходит релиз Потом ещё один Потом увольняется QA, который это заметил Потом меняется тимлид Потом проект переезжает с Jenkins на GitLab CI Потом весь отдел обсуждает, почему прод периодически отдаёт отрицательные цены Ты открываешь IntelliJ IDEA → Git History — Последнее изменение файла: 1 год назад — Последний коммит автора: 11 месяцев назад — Последний онлайн в Slack: 403 days ago — Статус Jira-задачи: In Progress — Комментарий в задаче:

“Вернусь после отпуска, быстро доделаю”

Отпуск, как выяснилось, был в 2023 Ты начинаешь расследование: — Кто закомментировал assert? — Почему тест зелёный? — Почему TODO никто не увидел? Тимлид говорит "тест проходит же"🤠