Решение задач по SQL полезно, чтобы закрепить знания после обучения или если требуется их освежить перед собеседованием. Это позволяет вспомнить правила составления и структуру запросов, а также используемый синтаксис. Но где брать задачи и как организовать процесс? 🤔

Можно, конечно, поднять необходимое СУБД локально, создать в нём базу с таблицами, настроив связи, типы данных и ограничения. Но это потребует времени и сил. Часто оптимальнее обратиться к сайтам-тренажерам, на которых можно прорешать задачи на создание выборки данных. Вот небольшая подборка таких сайтов, с которыми я работал ранее:

1. sql-ex.ru - старый ресурс с большим набором задач на выборку данных (+ на другие типы операций в рамках DML) и учебником. 📚 Задачи содержат ссылки на актуальные главы учебника, что позволяет использовать подход, при котором теоретический материал изучается ровно в том объёме, который необходим для решения конкретной задачи. При этом каждую задачу требуется решить ровно тем способом, который описывается в прикрепленной к задаче главе учебника. Т.е. если вы напишите запрос с использованием других функций или операторов, который даст аналогичный искомому результат, задача не будет засчитана, так как проверка происходит на нескольких базах, идентичных по структуре, но разных по наполнению.

2. sql-practice.com - тренажёр доступный без регистрации (нажимай старт и решай задачи), содержит набор задач на SELECT разной сложности, а также набор фильтров, позволяющий отобрать задачи на основе ключевых слов (например, на JOIN). 🔍 Помимо готовых задач ничто не мешает придумать свои и практиковаться в их решении. На прошлом проекте мы так и сделали и использовали тренажёр во время проведения собеседований.

3. sqltest.online - тренажёр, также доступный без регистрации, позволяющий решать задачи на разных СУБД. Задачи также ранжируются по степени сложности или по темам. Для каждой базы есть диаграмма структуры и связей и подробное описание входящих в неё таблиц с описанием каждой колонки и примером вывода одной записи. 📊 А ещё у проекта есть комьюнити, в котором можно в живом режиме задать вопросы и поделиться обратной связью.

Все эти ресурсы бесплатны и позволяют быстро приступить к практике. Если знаете еще годные площадки, поделитесь ими в комментариях! 💬

#sql #подборка
--
📺 Канал на YouTube |☕️ Поддержать автора на Boosty

Почем нынче менторство? 🤔

Если вы думаете обратиться за услугами ментора по тестированию, но не знаете, какие сейчас цены на рынке, то можете ознакомиться с результатами опроса на крупном канале по поиску менторов 📊:

https://t.me/qa_mentors/36709

В итоге распределение цен на услуги менторов по тестированию на конец 2024 года 💰:

• Бесплатно: ~22.22%
• 10-19$: ~22.22%
• 20-29$: ~16.67%
• 30-39$: ~16.67%
• 40-49$: ~5.56%
• 50-59$: ~5.56%
• 60-99$: ~5.56%
• От 100$ и выше: ~5.56%

Если у вас есть опасения насчет высокой стоимости услуг, то результаты опроса могут их развеять. Согласно им, доля менторов растет по мере уменьшения цены. Поэтому ментора можно найти под любые финансовые возможности.

#менторство #деньги
—
📺 Канал на YouTube | ☕️ Поддержать автора на Boosty

Работа с JSONB в PostgreSQL. 📚

Представьте что у вас есть таблица, в 1 из столбцов которой хранятся данные в формате JSONB.

JSONB - это бинарный формат хранения данных типа JSON.

В ходе работы нам может понадобиться получить выборку на основе значений каких-либо параметров объектов, содержащихся в этом столбце. В этой статье мы рассмотрим несколько полезных операторов и преобразований для работы с JSONB, а также примеры запросов, которые помогут найти нужные записи в таблице.

Для иллюстрации мы будем использовать следующий JSONB-объект, который будет храниться в столбце data таблицы users:

{ "id": 1, "name": "John Doe", "age": 30, "address": { "city": "New York", "zip": "10001" }, "hobbies": [ {"type": "sports", "name": "basketball"}, {"type": "music", "name": "guitar"} ] }

Теперь рассмотрим примеры запросов.

🔑 1. Найти запись в таблице по значению ключа

Допустим, нам нужно извлечь записи с именем John Doe. Для того, чтобы это сделать мы можем использовать оператор ->>:

SELECT * FROM users WHERE data\->>'name' = 'John Doe';

->> используется для извлечения значения по ключу из JSON-объекта и возвращает его в текстовом формате. В данном примере мы вернем только те записи, которые после извлечения значения ключа name и преобразования в текст будут = 'John Doe'.

🔑 2. Найти записи в таблице, у которых значение ключа > определенного числа

Теперь представим, что нам нужно найти записи, значение возраста в которых будет больше 25. Так как оператор ->> вернет нам строку, то сравнить ее с числом не получится. Для этого значение нужно преобразовать в число:

SELECT * FROM users WHERE (data\->>'age')::int > 25;

::int преобразует извлеченное значение ключа age в число. Таким образом в WHERE можно отфильтровать записи, значение age в которых превышает 25.

🔑 3. Найти запись по значению ключа объекта, вложенного в другой объект

Если нам нужно найти записи с городом New York, который находится внутри объекта address, мы можем использовать оператор ->:

SELECT * FROM users WHERE data\->'address'\->>'city' = 'New York';

С помощью -> мы извлекаем значение ключа address в формате JSONB и уже в нем, с помощью ->> извлекаем значение city в текстовом формате. Таким образом мы получим все записи, где значением city указан 'New York'.

🔑 4. Найти запись по значению ключа объекта, вложенного в список внутри другого объекта

Если мы хотим найти записи, где в массиве hobbies содержится хобби с названием guаitar, то можем воспользоваться оператором @> в запросе:

SELECT * FROM users WHERE data @> '{"hobbies": [{"name": "guitar"}]}';

С помощью оператора вложенности @> мы проверяем, содержит ли JSONB-объект hobbies в своем массиве другой JSONB-объект, с ключом name, значением которого является 'guitar'.

Таким образом мы можем выполнять поиск нужных нам записей, на основе значений ключа в JSONB-объекте. Следует помнить, что по мимо JSONB, данные также могут храниться в JSON формате и в этом случае мы не сможем выполнить оператор @> в запросе. Также здесь описана только часть возможностей работы с JSONB, более подробная информация описана в документации.

#sql #postgresql

Явные и неявные ожидания на примере Python Selenium.

Частый и популярный вопрос как на собеседованиях, так и в работе над автоматизацией UI-тестов. Попробуем разобраться. В качестве примера возьмём страницу -

https://www.selenium.dev/selenium/web/dynamic.html.

Представьте, что мы автоматизируем тест, проверяющий появление красного квадрата после нажатия кнопки "add a box!". Пример простого кода:

```
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from webdriver_manager.chrome import ChromeDriverManager
from selenium import webdriver

def test_red_box_adding():
service = Service(ChromeDriverManager().install())
wd = webdriver.Chrome(service=service)
wd.maximize_window()

```

Если попытаться выполнить функцию поиска элемента, возникнет ситуация, когда новый элемент, после нажатия кнопки, ещё не создался, а функция уже сработала, не нашла искомый элемент и выдала исключение.

Чтобы этого избежать, стоит добавить ожидание, которое позволит выполнить команду поиска в тот момент, когда элемент появится в DOM. Ожидания делятся на два типа: неявные и явные. Для выбора оптимальной стратегии поиска нужно разобраться, чем они отличаются.

? Неявные ожидания позволяют задать максимальное время, в течение которого драйвер будет ждать появления элемента, и только по истечении этого времени выбросит исключение, если элемент так и не найдётся. Пример:

driver.implicitly\_wait(10)

В этом методе драйвер задаёт время неявного ожидания равным 10 секундам. Данное ожидание будет действовать при поиске всех элементов (если только для конкретного поиска явно не будет указано другое время ожидания). Если элемент будет найден через одну секунду, то драйвер не будет ждать оставшиеся девять.

? Явные ожидания многократно (в пределах указанного времени) опрашивают страницу на предмет соблюдения условия и, когда оно выполняется, переходят к выполнению следующих команд. Реализуются с помощью WebDriverWait, который задаёт таймаут, и ExpectedCondition, задающего необходимое условие.

```
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
<...>

WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.ID, "box0")))
```

В данном примере драйвер в течение 10 секунд проверяет, что элемент с id="box0" присутствует в DOM. Если это так, то будет выполнена следующая инструкция.

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

https://www.selenium.dev/selenium/docs/api/py/webdriver_support/selenium.webdriver.support.expected_conditions.html.

❓ Какой тип ожидания выбрать? Выбор типа ожидания зависит от конкретной ситуации. Например, при поиске разных элементов с различными условиями может потребоваться задавать разные таймауты, и в таком случае явные ожидания будут предпочтительнее. Однако иногда удобнее задать один раз неявное ожидание на несколько секунд, что позволит ускорить написание простых однотипных тестов. При этом важно помнить, что даже с использованием ожиданий остаётся риск того, что элемент не появится в DOM к моменту истечения времени ожидания.

#python #selenium #aqa

Делюсь тестовым заданием для уровня intern/junior от 2GIS для тех, кто хочет попрактиковаться в тестировании API:

ссылка_на_тестовое_задание

В нем можно:
? проверить навыки тест-дизайна и написания баг-репортов
? попрактиковаться в работе с инструментом для отправки запросов, таким как Postman
? бонусом попробовать написать API автотесты

Рекомендую выполнить задание, а затем сравнить свое решение с решением из видео.

#практика #api

? Часто на работе узнаю какие-то мелочи, дополняющие уже имеющиеся знания по теории, инструментам или командам для работы с ними. Буду делиться такой информацией, так как она может оказаться полезной не только для меня.

?‍? Вчера, работая с базой данных, узнал от коллеги, как с помощью RETURNING в SQL-запросе получить данные из модифицируемых строк в процессе их обработки. Представьте, что нам требуется добавить запись в таблицу, где ей автоматически будет присвоен id, который нам нужно узнать для последующего использования. Выглядеть такой запрос будет следующим образом:

INSERT INTO table\_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...) RETURNING columnId; \-\- где columnId — наименование колонки с id

? Пример:

INSERT INTO Customer (FirstName, LastName, Address, City, PostalCode, Country, Email) VALUES ('Cardinal', 'Tom B. Erichsen', 'Skagen 21', 'Stavanger', '4006', 'Norway', '[email protected]') RETURNING CustomerId;

? В ответе вернётся id добавленной записи с информацией о клиенте.

? Это удобно при работе с нагруженными базами данных, где параллельно работает множество пользователей, и данные добавляются регулярно. Такой подход позволяет не писать дополнительный SELECT для сбора данных.

⚙️ RETURNING может использоваться в командах INSERT, UPDATE и DELETE.

Высокая конкуренция на рынке QA может порождать мысли в духе "лишь бы получить работу тестировщиком, а там и трава не расти". Попробую показать, почему не стоит цепляться за любую работу в QA и почему важно узнавать детали по проекту, в который вы получили оффер.

? Сфера и бизнес-контекст могут быть сложными сами по себе и при этом совершенно не вызывать у вас интереса. Вам хочется погрузиться в мир бухгалтерского учета или строительных смет? Вам хочется глубоко и детально вникать в особенности бизнес правил в совершенно не интересующей вас сфере для понимания работы функционала? Будет ли такая работа приносить вам радость? Да и технологии также могут вам не подойти. Например, у меня был короткий период тестирования на мобилках, который мне совершенно не понравился. Поэтому в отношении себя я четко понимаю что не хотел бы заниматься мобильным тестированием и не рассматриваю данное направление.

?Но если вы думаете, что это можно потерпеть, лишь бы был коммерческий опыт, то следует также обратить внимание на технологии и стек на проекте, так как они могут быть очень узко-специфичны. Ваш опыт работы с ними может оказаться просто невостребованным в дальнейшем, когда вы задумаетесь о смене работы. У меня так вышло с операционной системой OpenVMS, с которой я работал на своих первых проектах. Да, это был интересный опыт, который косвенно помог мне быстрее научиться работать с терминалом Linux и cmd. Но вакансий, требующих знания этой операционки, я с тех пор нигде не встречал.

?Еще обязательно следует узнать о текущей ситуации с QA на проекте, так как есть вероятность оказаться первым и единственным тестировщиком без каких-либо выстроенных до вас QA процессов. Если такой проект окажется для вас первым, то без обратной связи вам будет сложно понимать качество проделываемой вами работы. Также эта ситуация может вызывать высокий уровень стресса, ведь вам нужно будет с 0 и без помощи заниматься тем, в чем у вас еще нет опыта.

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

Помню при знакомстве с гитом меня смутило понятие pull request. Я пробовал сопоставить его с командой pull, и возникали вопросы. Если команда push заливает изменения из локального репозитория в удаленный (remote), а команда pull наоборот вытягивает изменения из remote хранилища в локальное, то для чего нужно создавать pull request (и почему по аналогии нет push request)? ?

Ответ в том, что pull и pull request совершенно разные действия (более того, pull request не команда git, а функционал GitHub).
Pull request - запрос на внесение изменений в код проекта, который позволяет другим участникам команды выполнить их ревью и принять решение включать эти изменения или нет. В случае положительного решения ветка с изменениями сливается с основной веткой проекта в удаленном репозитории. Механизм pull request позволяет контролировать качество кода и делает процесс внесения изменений в проект более безопасным.

git pull же является командой = комбинации команд git fetch + git merge. Сначала изменения забираются из определенной ветки удаленного репозитория, а затем вливаются в выбранную ветку локального хранилища. Это удобно когда требуется обновить локальный репозиторий.

Таким образом pull и pull request применяются в разных ситуациях и для разных целей. При этом, повторюсь, pull request - это фича GitHub. В GitLab, она называется уже merge request и как по мне такое название куда лучше отражает смысл.