Валерий | AQA Engineer | Автотестирование на Python | REST, gRPC, GraphQL

С чего начать автоматизацию Джуну на проекте? 🤔 В комментариях на этот вопрос резонно указали: нужна ли автоматизация на проекте? Всему свое время. Так же, как о наличии тестировщиков начинают задумываться тогда, когда продукт прошел фазу, в которой выясняется, что он действительно нужен и востребован, когда минимально работающий и необходимый функционал реализован, и пришло время задумываться о качестве. То же самое и с автоматизацией: если у вас продукт на ранней стадии, динамично меняющийся интерфейс, контракты и логика, автотесты будут слишком часто ломаться, а их поддержка станет очень дорогой. Вообще, некоторое время разработчики могут самостоятельно поддерживать автоматизацию на уровне юнит-тестов. 🛠 Поэтому во многих случаях введение автоматизации тестирования может оказаться не рентабельным. Существует и другая ситуация: продукт стабилен, но технологический стек очень устарел, иногда лучше в это дело даже не ввязываться. 😅 Однако есть и третий момент, когда, вроде бы, никто не против, и продукт в целом стабилен, но никто не готов выделять на это ресурсы. Поэтому нужно определиться: 1. Готова ли компания вложиться в автоматизацию? 2. Готов ли ты вложиться в автоматизацию и нужно ли это тебе? 🤔 3. Насколько технологический стек продукта подходит для автоматизации? 4. Какие аспекты можно автоматизировать в принципе? Положительный ответ на первый вопрос совсем не обязателен, если есть положительный ответ на второй вопрос, потому что, ну кто тебе запретит развиваться и овертаймить? Теперь перейдем к третьему вопросу. Мое мнение: если у тебя проект с нераспространенным или очень старым стеком, нужно очень хорошо задуматься, нужно ли это тебе вообще. 🤔 Если нужно, проанализируй существующие инструменты для автоматизации того, что тебе необходимо, и насколько хорошо они поддерживаются. Если с этим дела обстоят плохо, то автоматизация — это не обязательно автотесты, это любая рутина: подготовка тестовых данных, анализ данных (например, логов), развертывание нужного окружения и т. д. — это тоже автоматизация. 🔄 Допустим — у тебя обычный веб и огромное желание. 💡 Я больше люблю бэк, так как он быстрее и стабильнее, поэтому буду говорить о нем. 🚀 📚 Первое, что стоит сделать, — это выучить хотя бы базовые знания по языку программирования, который тебе нравится. Сейчас есть ChatGPT, который может помочь ничуть не хуже разработчика, особенно на старте. 🔍 Второе — пиши простой и понятный код. Главное, чтобы ты его понимал, потому что возиться с автотестами будешь тоже ты, потом отрефачишь. 🐳 Третье — после того как ты написал хоть что-то рабочее, что приносит пользу, учись запускать это в каком-нибудь Docker. 🚀 Четвертое — отладил Docker — беги внедрять это в пайплайн. От тестов есть польза только тогда, когда они работают, и чем раньше они будут выполняться, тем лучше. 😃 Лучше иметь один-два стабильных теста, которые уже сейчас работают в пайплайне, чем локально иметь десяток тестов, которые никто кроме тебя не может запустить и которые постоянно падают. Не нужно писать миллиард тестов на одну ручку; пусть у тебя будет хотя бы по одному позитивному кейсу на каждый метод для смоков, потом уже будешь расширять. И вот только после того, как это всё запустится и будет работать, прикручивай Allure-отчет, потому что, исходя из практики, чаще всего его смотреть будешь именно ты. Разработчиков и других больше интересует бинарный результат: прошли / не прошли. ✅ К моменту, когда ты всё это сделаешь, твой код обрастет такой большой портянкой вспомогательных функций, методов, логов и марок, что ты уже сам придешь к тому моменту, что пора это говно рефачить. 😂 В кратце как-то так. 😉 Ну, а если хочешь научиться писать код так, чтобы все это было поддерживаемо, читаемо, красиво и удобно. Делать отчеты, уведомления и запускать всё это добро в пайплайнах. 🎓 Приходи на обучение, научу всего за месяц, старт уже 3 марта! TG-сообщество | Обучение |Отзывы

Всем привет, на этой неделе заканчивается 6 поток курса "Автоматизация тестирования REST API Advanced (Python)" И хочу поделиться отзывом одного из учеников. Если честно я считаю мой тренинг одним из лучших, некоторые их моих студентов уже работают или устроились в озон, при этом без рефералки, а чисто на скиллах, в том числе полученными и меня на обучении. Тренинг позволит вам научиться писать тесты красиво, поддерживаемо и правильно. Мы построим фреймворк от простого к сложному, подключив все это добро в пайплайн с настройкой уведомлений и прочего. Позволит ли он вам понять, как поднять и настроить процесс автоматизации тестирования с нуля? Думаю да, но нужно учитывать, что знать основы Python все-таки нужно. Обучение стартует 3 марта, а с конца следующей недели я в отпуске и не смогу делать и подписывать документы, поэтому если кто-то хочет попробовать обучиться за счет работодателя, лучше поторопиться) В общем велкам) TG-сообщество | Обучение |Отзывы

Давайте немного пообщаемся, напишите в тредик темы про которые бы хотели узнать мой ответ в форме поста)

Дополню предыдущий пост и расскажу про двусторонние и другие очереди: Методы .append и .pop позволяют использовать список list как стек или очередь (если вызывать только .append``и .pop(0)`, то получится дисциплина обслуживания LIFO). Однако вставка и удаление элемента из левого конца списка (с индексом 0) обходятся дорого, поскольку приходится сдвигать весь список. Есть такая структура как `deque`, она реализует большинство методов list и добавляет несколько новых, связанных с её назначением, например, popleft и rotate. Однако, существует и скрытая неэффективность: удаление элементов из середины deque производится медленно. Эта структура данных оптимизирована для добавления и удаления элементов только с любого конца. Помимо deque, в стандартной библиотеке Python есть модули, реализующие другие виды очередей. Содержит синхронизированные (т. е. потокобезопасные) классы Queue, LifoQueue и PriorityQueue. Они используются для безопасной коммуникации между потоками. Все три очереди можно сделать ограниченными, передав конструктору аргумент maxsize, больше 0. Однако, в отличие от deque, в случае переполнения элементы не удаляются из очереди, чтобы освободить место; вставка новых элементов блокируется, т. е. программа ждет, пока какой-либо другой поток удалит элемент из очереди. Это полезно для ограничения общего числа работающих потоков. multiprocessing Реализует собственную неограниченную очередь SimpleQueue и ограниченную очередь Queue, очень похожие на аналоги в пакете queue, но предназначенные для межпроцессного взаимодействия. Чтобы упростить управление задачами, имеется также специализированный класс multiprocessing.JoinableQueue. asyncio Предоставляет классы Queue, LifoQueue, PriorityQueue и JoinableQueue, API которых построен по образцу классов из модулей queue и multiprocessing, но адаптирован для управления задачами в асинхронных программах. heapq В отличие от трех предыдущих модулей, heapq не содержит класса очереди, а предоставляет функции, в частности heappush и heappop, которые позволяют работать с изменяемой последовательностью как с очередью с приоритетами, реализованной в виде пирамиды. Говоря честно, особого помнить все эти структуры данных, особенно тестировщику особого смысла нет, так как применять вы их будете с очень низкой вероятностью. Но лучше знать об их существовании, иногда может пригодиться) Если что, это не последний пост, про структуры данных)

Про очереди: В предыдущем посте про структуры данных мы обсуждали контейнерные типы данных, такие как кортежи и списки. В этом посте хочу рассказать о очередях (Queue). Проблема, которую решают очереди, например: 1. Удаление элементов во время итерации Вы когда-нибудь пытались пройтись по списку и на лету удалять из него значения, например, чтобы на второй итерации вложенного цикла не обрабатывать уже обработанные элементы? Если пробовали, то наверняка сталкивались с ошибкой:

RuntimeError: list changed size during iteration

Очереди помогают избежать этой проблемы, так как они позволяют безопасно управлять элементами, которые нужно обработать или удалить. 2. Параллельная обработка данных Представьте, что у вас есть параллельная обработка в разных потоках, например, чтение из Kafka-топика. Вам нужно приостановить чтение новых сообщений до тех пор, пока не будут обработаны все ранее полученные. Очереди идеально подходят для таких сценариев, так как они позволяют организовать буфер между продюсером и консумером данных. Что такое очередь? Очередь — это структура данных, которая работает по принципу FIFO (First In, First Out), то есть "первый пришел — первый ушел". Это означает, что элементы добавляются в конец очереди, а извлекаются из её начала. Рассмотрим простой пример с потребителем (consumer) и производителем (producer): Где мы просто запускаем два потока, один на чтение другой на заполнение очереди (эмулируем сервис который шлет сообщение в очередь). И в качестве примера просто ищем значение в очереди со значением 3, если не находим в течение 10 попыток, то выбрасываем исключение и останавливаем потоки.

import threading
import queue
import time


QUEUE = queue.Queue()
EVENT = threading.Event()


def producer():
    for i in range(5):
        print(f"Добавляем элемент {i} в очередь")
        QUEUE.put(i)
        time.sleep(1)
        if EVENT.is_set():
            break
    QUEUE.put(None)


def consumer(callback):
    count = 0
    while True:
        item = QUEUE.get()
        QUEUE.task_done()
        if item is None:
            break
        if callback(item):
            EVENT.set()
            break
        count += 1
        if count == 10:
            EVENT.set()
            raise AssertionError("Item not found in 10 attempts")


def test_consumer():
    callback = lambda item: item == 3
    threading.Thread(target=producer, daemon=True).start()
    threading.Thread(target=consumer, args=(callback,), daemon=True).start()

Особенности очередей: 1. Элементы удаляются после обработки - после выполнения метода get() элемент удаляется из очереди. В случае со списком мы не смогли бы на лету удалять обработанные элементы и одновременно добавлять новые. 2. Ограничение размера очереди - можно указать максимальный размер очереди с помощью параметра maxsize например queue.Queue(maxsize=10). Если очередь заполнена, продюсер приостанавливает добавление новых элементов до тех пор, пока потребитель не освободит место. 3. Потокобезопасность Очереди из модуля queue поддерживают многопоточность, что делает их удобными для параллельных задач. Когда использовать очереди? Очереди — это мощный инструмент, но их не стоит использовать бездумно. Вот несколько рекомендаций: - Используйте очереди, если вам нужно управлять порядком обработки данных (FIFO, LIFO) или организовать взаимодействие между потоками. - Не используйте очереди, если задача решается с помощью более простых структур данных, таких как списки, кортежи или словари. Очереди — это удобная структура данных для определенного класса задач, таких как параллельная обработка данных или управление порядком выполнения операций. Однако, для простых задач лучше использовать более распространенные структуры, такие как списки или словари. TG-сообщество | Обучение |Отзывы

Привет, немного оф топ)) Пост для тех кому за 30 🤣 У меня теща, лютый медик с двумя высшими медицинскими образованиями и провизор с 30-летним стажем, то есть человек, который реально очень круто разбирается в лекарствах и к которому можно обратиться с любым советом относительно пользы того или иного лекарства, то есть из тех людей кому реально интересно работать в своей области (примерно как мне в программировании и тестировании). Пост не реклама, а абсолютный рекомендасьен, подписывайтесь, задавайте вопросы)) Вот, например, интересный пост про то, что таблетки оказывается нельзя делить по насечкам, лично я был убежден, что насечки именно для этого и есть. Ну, а следующий мой пост будет уже про очереди в python)

Python: почему это идеальный язык для автоматизации Не у всех, но у многих рано или поздно возникают проблемы: - Рутина. - Скука. - Много ручного труда. - Непонятно, куда развиваться. Решение? Учить Python! =) 7 лет назад на первой работе я столкнулся с этим. Проект был сложный в плане бизнеса, но технически — просто Oracle-база и приложение на хранимых процедурах. Развиваться было некуда. Мысль изучать Python подкинул друг-программист. Я быстро понял: не нужно углубляться в устройство языка, чтобы решать задачи. Типа, зачем знать, как устроен телевизор, если главное — уметь переключать каналы? Python — это конструктор. Нужно просто собрать из деталей то, что работает. Отправить запрос? Бери `requests`, заполняй параметры — готово. Работать с файлом? Стандартные конструкции, указал путь — файл читается. Программировать на Python легко. Никаких сложных конструкций, всё читается как текст.

for i in range(10):
    if i == 9:
        print("Досчитали до 9")

Или так (псевдокод):

для i в диапазоне(10):
    если i == 9:
        печатать("Досчитали до 9")

Если вы думаете, что это слишком простой пример, то нет — весь код на этом и построен. Безусловно, многие из вас уже видели код и могут сказать: «Да иди ты, мы видели код, там не всё так просто!» Да, конечно, кто много пишет, уже применяет ООП, паттерны и прочее. Но если вы знаете английский хотя бы на минималках, то должны понимать, что кто-то на английском разговаривает как Бэтмен, а кому-то хватает простых фраз вроде: «CARD», «Where is...», «This» (и ткнуть пальцем). То же самое и с языками программирования. На базовом уровне простого набора операторов хватит, чтобы автоматизировать кучу задач. В общем, итог: не надо бояться. Сначала может быть сложно поставить язык, настроить среду разработки, но потом писать простые программы — это легко. Второй момент, который я понял: Python — это язык автоматизации. Он гипер-супер-пупер удобен. Мой первый большой проект, который автоматизировал процесс деплоя десктопного приложения, по сути, был автоматизацией рутинных ручных действий. Он затрагивал вообще всё: 1. Копировал библиотеку на сетевой диск. 2. Запускал RDP. 3. Через RDP запускал CLI-тулзу (через FAR, помните такой?). 4. Проставлял статус задачи в таск-трекере (через базу данных). Может звучит гиперсложно, но на самом деле это было написано на суперпримитивном коде. И тогда я понял, что в Python на каждый чих есть своя библиотека: для работы с удаленным рабочим столом, для CLI-интерфейсов, для баз данных, файлов, десктопных приложений, не говоря уже о вебе. Это реально суперкрутой швейцарский нож. Теперь я понимаю, что для решения любой задачи мне по сути хватит одного языка. Он работает на любой операционке, остается только найти нужную библиотеку, которых огромное множество. Моя автодеплоилка экономила около 20 минут рабочего времени. Я наливал себе кофе, запускал скрипт и восхищался, какой я волшебник, видя, как всё само открывается, нажимается, переносится, а еще пишутся логи, как у настоящего программиста. Каждый твой проектик — это как твой ребенок, чтоли. Это безумно интересно! А самые прикольные профиты: - У тебя появляется как минимум 20 минут времени, чтобы попробовать изучить что-то новое. - Коллеги, которые тоже горят автоматизацией, но еще не умеют, смотрят на тебя как на боженьку, потому что ты смог поднять всю эту магию, а они — нет. Это очень сильно подняло мою уверенность и мотивацию расти, делать интересные и полезные штуки, которые еще и очень хорошо помогают на перфоманс-ревью. Если вы хотя бы на минималках знаете Python и у вас есть API, на котором вы хотите что-то сделать на работе, можете попробовать этот мастер-класс. На него очень хорошие отзывы, и главное — вы сможете применить знания сразу и увидеть результат тоже сразу. А так же рекомендую почитать книгу, обложку которой я разместил в посте, она в свое время очень сильно мне помогла) TG-сообщество | Обучение |Отзывы

Привет, сегодня поделюсь шпаргалкой по Python, для начинающих) https://devhints.io/python TG-сообщество | Обучение |Отзывы

Хочу поделиться отзывом, который, написал один из студентов предыдущего потока, полностью его можно прочесть, как это не странно в отзывах) Важно отметить, данное обучение действительно не подойдет тем, кто изучает прям совсем с нуля. Уровень с которого можно не бояться Junior+, для вас это будет прям супер прорыв. Так же стоит отметить, что у меня училось много людей и middle и senior уровня и судя по отзывам каждый находил для себя много нового. Многие приходили по рекомендации или даже после других именитых школ. Так, что кто еще задумывается можете присмотреться, ссылку на обучение можете найти в футере поста. Следующий 7 поток стартует в начале марта. TG-сообщество | Обучение |Отзывы

Хочу поделиться отзывом, который, написал один из студентов предыдущего потока, полностью его можно прочесть, как это не странно в отзывах) Важно отметить, данное обучение действительно не подойдет тем, кто изучает прям совсем с нуля. Уровень с которого можно не бояться Junior+, для вас это будет прям супер прорыв. Так же стоит отметить, что у меня училось много людей и middle и senior уровня и судя по отзывам каждый находил для себя много нового. Многие приходили по рекомендации или даже после других именитых школ. Так, что кто еще задумывается можете присмотреться, ссылку на обучение можете найти в футере поста. Следующий поток стартанет в начале марта. TG-сообщество | Обучение |Отзывы

Как устроено наше тестируемое приложение Давайте немного расскажу о том, как устроено наше тестируемое приложение. Это только небольшой кусок. Как вы знаете, я уже второй год работаю над расширением функциональности тестируемого приложения, чтобы можно было попрактиковаться в работе с различными системами и видами API. Сейчас это довольно большой "франкенштейн", в который накручено большое количество систем в учебных целях, поэтому рассматривать его структуру как применение на каком-либо боевом сервисе с высокой нагрузкой не стоит. Тем не менее, что у нас тут есть: - Только на текущей схеме 6 микросервисов (на самом деле их почти в два раза больше); - Один GraphQL сервис; - Один gRPC сервис; - ClickHouse для сбора аналитики по успешности и неуспешности регистраций; - Redis для кэширования информации о пользователях; - PostgreSQL для хранения всей информации о системе; - RabbitMQ для регистрации событий о осуществлении регистрации и других событий, а также для отправки писем на почту; - Kafka для накопления очереди о регистрации и повторной попытки регистрации, если в процессе произошли какие-либо системные, не пользовательские ошибки. GraphQL и gRPC сервисы по большей части дублируют функционал и контракты REST сервиса, чтобы на примере было видно, в чем схожи и чем отличаются процессы тестирования и построения фреймворков автоматизации для разных типов API. В моей картине мира итогом прохождения всех модулей программы (которая постепенно реализуется) станет очень большой фреймворк, который затрагивает множество интеграций и систем. Овладев этим, у AQA Engineer больше не будет нерешаемых задач. А также будет происходить параллельная разработка фреймворка, который позволит автоматизировать развертывание фреймворка автотестов. TG-сообщество | Обучение |Отзывы

Всем привет! Меня зовут Валерий Меньшиков. Я Senior Python Software Engineer , до этого я более 6 лет работал как QA Automation Engineer. В этом канале я делюсь информацией по автоматизации тестирования на Python и раскрываю сложные темы автоматизации такие как kafka, gRPC, REST, GraphQL, работу с различными базами данных, кодогенерацию и многое другое. - Имею 7 лет опыта программирования на Python - Являюсь разработчиком инструментов автоматизации и тестовой платформы включающей все выше перечисленные технологии - Сильный эксперт, спикер и предодаватель - Умею объяснять очень емко и грамотно. Если ты хочешь стать крутым инженером который: - владеет самыми современными технологиями и инструментами - растет в ЗП и не боится даже самых сложных проектов - уверен, что всегда будет востребован на рынке. То тогда ты попал по адресу ) Самые интересные на мой взгляд посты с которых можно начать: - Python: почему это идеальный язык для автоматизации - С чего начать автоматизацию Джуну на проекте? 🤔 - Как устроено наше тестируемое приложение - Серия постов как работать с кафка в автотестах тут - Статья про gRPC и работу с ним в автотестах - Одна из самых больших ошибок, которую можно совершить - Способы построения тестовой архитектуры автотестов: часть1, часть2, часть3 - Доклад с QA Python Meet Up туть Список, буду потихоньку дополнять) TG-сообщество | Обучение |Отзывы

Я ВСЕ ЗНАЮ Одна из самых больших ошибок, которую можно совершить, — это убежденность в том, что "мне этот мир абсолютно понятен" и "меня больше ничему не нужно учить". Это опасное заблуждение часто встречается у специалистов кто уже не первый год в IT. Некоторые из них, с упоением описывают очередной REST-клиент или Pydantic, чувствуют себя высококлассными программистами, по сути занимаясь рутинной работой которую может осилить практически каждый. К сожалению, такое положение дел ведет к застою в развитии. Люди "каменеют" в своих знаниях и навыках и убеждениях, типо ну я же умею писать код, тестить и тп (вставь нужное), чему можно меня научить. Не хотят принимать новое, потому что зачем? "Мы писали так триста лет, будем продолжать так же", зачем что-то теплое и привычное менять. Взаимодействовать с такими людьми тяжело, порой там возникает какая-то твердолобость, сопостовимая с какой-то тупизной)) У меня есть товарищ, который пытался вредрить кодогенерацию в одной известной компании, и его завернули потому что, зачем? Ну видать колоссальное сокращение времени на разработку тестов и сокращение ошибок при написании, в расчет не берется. С такими людьми тяжело работать. Если вы когда-либо занимались спортом, то знаете, как трудно переучивать человека, у которого уже выработаны устоявшиеся привычки. Гораздо проще учить новичка с чистого листа. Тем не менее, важно понимать, что существует и положительный путь развития. Люди, продолжают чтение книг, изучают различные подходы, смотрят курсы и обмениваются опытом. Появляется насмотренность и после этого начинает вырабатываться свой собственный стиль. Эта проблема актуальна не только в IT. Примером могут служить некоторые врачи, которые, несмотря на многолетний опыт из-за отсутствия желания учиться, игнорируют новые достижения медицины. И не знают, что иногда то что считалось полезным в прошлом, может оказаться устаревшим или даже вредным сегодня. То же самое возникает и у некоторых айтишников, которых триста лет назад научили неправильно, и теперь чтобы, прикрутить что-то новое они думают: "Епт мне же теперь, придется переписывать все тесты", что бы что-то добавить. А ведь этого можно было бы избежать если держать себя в тонусе и периодически изучать что-то новое. Я убежден, что невозможно научиться всему раз и навсегда и в нашей сфере это процесс непрерывный. Что меня радует в моей деятельности, так это возможность обучать и общаться с людьми разного уровня, от начинающих можно подчерпнуть какие-то смелые подходы, а от сеньерных чуваков, интересные архитектурные решения, новые инструменты и библиотеки. Это позволяет внедрять новые подходы в свое обучение, тем самым прокачивая всех участников, включая меня. К сожалению, позиция "я самый умный" часто приводит к застою, в то время как настрой "я еще недостаточно крут" открывает двери для развития. На собеседованиях такие кандидаты часто производят лучшее впечатление. Человек, который излучает уверенность, иногда оказывается не таким уж компетентным, а тот, кто скромно говорит о своих знаниях, может удивить глубиной своих знаний и навыков. Помните: всегда есть возможность учиться и расти, независимо от вашего текущего уровня. Открытость к новым знаниям и опыту обеспечит вам устойчивый успех и развитие. TG-сообщество | Обучение |Отзывы

Продолжение к серии постов. Самый фундаментальный тип последовательности — список list, изменяемый контейнер. Я думаю, все много работали с ними, поэтому рассмотрим следующий фундаментальный тип и его отличия от list. Следующий фундаментальный тип последовательностей в Python — это tuple. Многие называют tuple неизменяемым списком, но это не совсем так. Видя в коде кортеж, мы точно знаем, что его длина никогда не изменится. Кортеж потребляет меньше памяти, чем список той же длины (об этом чуть позже) и позволяет интерпретатору Python выполнить некоторые оптимизации. Однако не забывайте, что неизменность кортежа касается только хранения ссылок — их нельзя ни удалить, ни изменить. Но если какая-то ссылка указывает на изменяемый объект и этот объект будет изменен, то значение кортежа изменится. (Смотрите рисунок к посту.) Лучше не использовать кортежи для хранения изменяемых объектов, так как это может привести к ошибкам. Например, такой кортеж нельзя будет сделать ключом словаря или отфильтровать с помощью множества (set), так как такой объект не будет хэшируемым, то есть тем, который никогда не меняет своего значения. А теперь о том, почему кортеж производительнее списка: 1. Чтобы вычислить кортежный литерал, компилятор Python генерирует байт-код для константы типа кортежа, состоящий из одной операции, тогда как для спискового литерала сгенерированный байт-код сначала помещает каждый элемент в стек данных в виде отдельной константы, а затем строит список. 2. Имея кортеж t, вызов tuple(t) просто возвращает ссылку на тот же t. Никакого копирования не производится. Напротив, если дан список l, то конструктор list(l) должен создать новую копию l. 3. Благодаря фиксированной длине для экземпляра tuple выделяется ровно столько памяти, сколько необходимо. С другой стороны, для экземпляров list память выделяется с запасом, чтобы амортизировать стоимость последующих добавлений в список. 4. Ссылки на элементы кортежа хранятся в массиве, находящемся в самой структуре кортежа, тогда как в случае списка хранится указатель на массив ссылок, размещенный где-то в другом месте. Косвенность необходима, потому что когда список перестает помещаться в выделенной памяти, Python должен перераспределить память для массива ссылок, добавив места. Дополнительный уровень косвенности снижает эффективность процессорных кешей. более подробно можно посмотреть тут TG-сообщество | Обучение |Отзывы

Всем привет! Кто-то показывает свою экспертизу демонстрируя свою машину, квартиру, путешествия)) Этот этап я уже прошел 🤣 А если серьезно, я давно хотел создать что-то открытое и полезное для быстрого создания фреймворков для тестирования API. У меня уже есть такой проект, но пока он находится в приватном репозитории. Поскольку у меня нет времени на разработку большого проекта, я решил выпустить первую часть: генератор REST-клиента. В его основе уже используется мой любимый логгер, знакомый всем моим студентам, а также есть возможность сгенерировать асинхронный клиент. На python к сожалению инструмента, который бы мне понравился я не нашел 🤔 Вчера состоялся первый релиз моего опенсорс-проекта! 🎉 Для тех, кто пишет автотесты только на Python, это отличная возможность значительно сократить время на разработку клиента. Если вам понравилось, ставьте лайк, подписывайтесь и ставьте звездочку на GitHub! В нашем курсе professional мы как раз будем разрабатывать инструмент для ускорения развертывания проектов. TG-сообщество | Обучение |Отзывы Ссылка на проект тут: https://github.com/ValeriyMenshikov/restcodegen

Всем привет, давненько не было постов, так как занимался подготовкой к докладу. Вчера я выступал на внутреннем митапе посвященном использованию нашего фреймворка для автотестирования. Напомню тем кто мало со мной знаком, более 6 лет я проработал в автотестировании, а сейчас я старший разработчик в группе разработки Python платформы. И мы пилим фреймворк который, помогает разработчикам разрабатывать, аналитикам анализировать, а тестировщикам тестировать)) Где буквально каждый пользователь нашего фреймворка может сгенерировать себе нужный набор клиентов, будь то база данных, кэш, кафка , REST или gRPC клиент, при этом не решая сложные технические задачи. Почему сложные, для этого достаточно посмотреть доклад как у нас все устроено ну или почитать по этой ссылке на хабре. Но даже не смотря на всю сложность системы внутри озон, у большинства автотестеров возникают типовые проблемы, в виде генерации клиентов, логгирования клиентов, того же самого сбора coverage. Внедрения практик по поддержки качества кодовой базы. И именно поэтому у меня сейчас в записи модуль по разработке такой "платформы", где один раз мы напишем фреймворк, который закроет эти проблемы и следующие проекты мы будем просто генерировать) P.S видео это первый урок модуля professional ) TG-сообщество | Обучение |Отзывы

Можно ли стать усатым инженером после курсов? Уже полгода я работаю старшим разработчиком, и чем больше работаю, тем меньше верю в истории о том, как люди, нарисовав опыт, якобы залетают на позиции за 300k/наносек. У меня в IT идет восьмой год, из которых я больше пяти лет пишу на Python. Можно получить знания, но нужно научиться решать большой класс задач, знать возможности языка, которые помогут эти задачи решать. И сейчас, скажу я, сижу за компьютером и все больше накапливаю опыт решения именно разработческих задач. Например, сейчас у меня в разработке задача написать асинхронную параллельную обработку последовательностей сообщений с возможностью накопления буфера по количеству сообщений или тайм-ауту на накопление для каждой последовательности. Упрощенную схему, как у меня это работает сейчас, я нарисовал, схема приложена к посту. Напомню, что у меня не продуктовая разработка, а разработка платформы для разработчиков, поэтому то, с чем будет работать пользователь нашего фреймворка, заключено в верхней части схемы, в блоке “service code”, то есть работает только с уже обработанными сообщениями. Остальное все реализовано нашей командой. Упрощенно это выглядит так: gRPC-сервис для каждой схемы создает стрим и отсылает запрос с последовательностями, в каждой последовательности n-ное количество сообщений. Опустив всю дополнительную логику, есть основная main task, которая получает последовательности и для каждой последовательности создает свою асинхронную buf task на накопление буфера. После того как буфер накапливает нужное количество сообщений, он отдает их в main task, а та, в свою очередь, накопленный батч сообщений отдает клиенту (разработчику). Скажу честно, это действительно разрывает мозг. Без помощи своих коллег я вряд ли смог бы такое написать. Недавно я общался с продюсером, она хотела сотрудничать и предлагала сделать услугу типа «сопровождение до оффера». Честно, я не хочу брать на себя ответственность, и все такие истории я больше считаю инфоцыганством. Моя аудитория в большей своей части — это специалисты с опытом, и обещать им позицию сеньора после моего обучения я не могу. Я могу выступить как раз в роли более опытного коллеги, преподавателя. Я даю знания, которые наработаны огромным количеством проб и ошибок, выбираю самые эффективные инструменты, предоставляю песочницу, на которой можно практиковаться и научиться решать наиболее часто встречающиеся задачи в автоматизации тестирования. Это сильно сокращает путь к «усатой» позиции сеньора, но пока студент не обкатает эти решения, не внедрит их на своих проектах и не соберет те бонусы для реального проекта и бизнеса, полное осознание не дойдет. Поэтому я не могу гарантировать высоких позиций после обучения, но я могу очень сильно сократить этот путь. TG-сообщество | Обучение |

Всем привет! Несмотря на то, что канал у меня про автоматизацию, мне кажется, что сейчас довольно актуальная тема крипты и продуктов связанных с ней. У меня есть друг который давно варится в этой теме и мы планируем выпустить курс «Как проводится тестирование в WEB3. Blockchain. КриптоБаза» Курс будет проводить Артур - QA Team Lead в одной из известных компаний в мире Web3 с опытом более 5+ лет. Он расскажет как сам пришел в блокчейн, базовые отличия DEX/CEX, как тестировать смарт-контракты и многое другое. План курса: 1. Основы блокчейна. 2. Основы криптографии. 3. Децентрализация. 4. Создаем ваш первый web3 кошелек + изучаем популярные биржи. 5. Трейдинг криптовалюты. 6. Начало тестирования в WEB3. Логика большинства продуктов. 7. Отличия Bridge, Staking, Launchpads и как их тестировать. 8. Что такое testnet/mainnet? Почему транзакции такие дорогие? 9. Сети для тестирования. Отличия EVM от других. 10. NFT что это такое и как это тестировать? 11. Реальный проект на котором можно протестировать своими руками Bridge + поделимся всей тестовой моделью (тест-кейсы и чек-листы). 12. Самые распространные вопросы на собеседовании для QA Web3. В крипте сейчас одни из самых высоких зарплат в среднем QA Web3 уровня Middle зарабатывает от 2000$ до 4000$. Senior от 3000$ до 5000$ и напомню речь про ручное тестирование. Если что это не реклама, а скорее вброс на тему, был ли бы вам интересен курс по РУЧНОМУ тестированию крипты. Потому что исходя из этого мы будем думать делать курс с такой программой или нет) 👍 - интересно 💩 - нет TG-сообщество | Обучение |

Структуры данных. На собеседования довольно часто спрашивают структуры данных. Самый простой ответ это, списки, кортежи, словари, множества эти структуры знают все кто работал с Python. Но можно этот ответ расширить и объединить в группы, такие как "последовательности", "словари" и "множества" об этом мы и поговорим в следующих постах. Начнем с первых, последовательностей. Последовательности могут быть контейнерные: list, tuple, collections.deque Плоские: str, bytes, array.array В контейнерных последовательностях хранятся ссылки на объекты любого типа, тогда как в плоских последовательностях – сами значения прямо в памяти, занятой последовательностью, а не как отдельные объекты Python. Плоские могут хранить только элементы одного типа (см рисунок). Плоские последовательности компактнее, но могут содержать только значения примитивных машинных типов, например байты, целые числа и числа с плавающей точкой. Каждый объект Python, находящийся в памяти, имеет заголовок с метаданными (на рисунке это закрашенные клетки). У простейшего объекта, float, имеется поле значения и два поля метаданных: - ob_refcnt: счетчик ссылок на объект; - ob_type: указатель на тип объекта; - ob_fval: число типа double (в смысле C), в котором хранится значение с плавающей точкой. Каждое из этих полей занимает 8 байт. Потому-то массив float гораздо компактнее, чем кортеж float: массив – это один объект, хранящий сами значения с плавающей точкой, а кортеж состоит из нескольких объектов: сам кортеж и все содержащиеся в нем объекты типа float. Последовательности можно также классифицировать по признаку изменяемости: Изменяемые последовательности: Например, list, bytearray, array.array и collections.deque. Неизменяемые последовательности: Например, tuple, str и bytes. Знание структур данных позволяет более эффективно использовать средства языка, например, для хранения большого количества чисел можно использовать array так как он будет занимать гораздо меньше места в памяти чем list, c другой стороны, если часто добавляем или удаляем элементы из списка возможно лучше будет использовать очередь deque , но обо всем этом следующих постах. TG-сообщество | Обучение |

Всем привет, уже завтра стартует 6 поток обучения REST API Advanced. Когда то он был Advanced сейчас бы я его назвал Base, почему? Потому, что там включены все темы, которые я уже считаю базовыми. 1. Мы научимся писать "core" библиотеки для логов. 2. Изучим несколько паттернов проектирования для тестового фреймворка. 3. Изучим, что проверять и как, и сделаем это так что, наши тесты не будут захламлены неимоверным количеством явных проверок, но они будут выполняться по дефолту, что сделает наши тесты минималистичными и красивыми. 4. Научимся писать фикстуры, декораторы, контекстные менеджеры. 5. Напишем свой докер файл и научимся запускать тесты в контейнере 6. Сможем собирать покрытие сервиса автотестами, чтобы видеть что еще не протестировано и делать отчеты о прогоне. 7. Зарегистрируем своего телеграм бота, и настроим нотификацию в канал с отчетами о прогоне тестов и покрытии сервиса тестами. 8. Переедем в Gitlab и напишем свой пайплайн, который будет запускать тесты, рассылать уведомления и публиковать отчет. С первого дня занятий наши тесты будут запускаться в CI\CD GitHub Actions. А самое важное все это будет сделано всего за месяц, и без неоходимости сидеть и слушать часовые вебинары. Все видео нарезаны на мини части с презентациями, это не просто скринкаст экрана с объяснением в риалтайме, это подобраные слова без лишней воды, чтобы давать только нужную информацию и не тратить время слушателя. Поэтому кто еще хочет успеть попасть в поток, велкам, следующий будет только в начале марта. Переходи по ссылке "Обучение" TG-сообщество | Обучение |