QAжется, работает!
Open in Telegram
Канал про качество ПО и всего, что влияет на качество продукта
Show more608
Subscribers
No data24 hours
-17 days
+130 days
Posts Archive
Еще один способ ускорения тестов
Занимался ускорением тестов на проекте УТ. Обсуждал с Клодом возможные варианты, и он подкинул один неочевидный для меня способ. Может быть кому-то еще будет полезным.
У меня на проекте для каждой джобы в тестах запускается одноразовый раннер. На нем готовится окружение, запускаются тесты, после чего раннер удаляется. Таких джоб 60. И в каждой джобе запускается контейнер с БД и в контейнере идут миграции.
Раньше мы использовали раннеры в GitHub Actions, и там миграция занимала 10 секунд. И все 60 джоб с тестами запускались одновременно, потому что не было ограничений на раннеры. Но после переезда с GitHub Actions на раннеры в Яндекс Облаке миграции БД замедлились с 10 секунд до 2,5 минут. Плюс появилось инфраструктурное ограничение: не больше 12 раннеров одновременно. При 60 джобах и лимите в 12 одновременных запусков это добавило 10–12 минут к пайплайну. Возможно, причиной стали жесткие диски в Яндекс Облаке (но это не точно, не проверял).
Клод и говорит: «Так давай разместим каталог данных MySQL на tmpfs?» Файлы БД будут лежат не на дисках, а прямо в оперативной памяти. Профит. Было 2,5 минуты, стало 20 секунд. Миграции ускорились в 7 раз.
Но есть нюансы, tmpfs занимает оперативную память, а после остановки контейнера с БД данных у вас не останется. Мне сохранять данные не нужно, потому что и так после завершения джобы раннер гасится и с ним умирают все данные. А 8 ГБ оперативы раннера пока хватает на всю инфру.
Вывод такой, если вам нужно ускорить тесты, обратите внимание на подготовку окружения. Возможно, там есть пространство для ускорения.
Динамические тесты - база
Если вы думали что история с тестированием группировщика закончилась, то нет, не закончилась.
Вот мы написали статические тесты - они помогают нам провалидировать отдельные требования к группировщику (отдельный сервис, который за счет штрафов и комбинаторики выбирает наилучшие группировки исходя из заданных параметров), но не помогают нам увидеть, как система ведет себя в динамике.
Потому что, например, перед обедом, когда, как правило, нагрузка выше, мы можем отправить всех курьеров в поездку с 1 заказом, и на обеденный пик в пиццерии не останется ни одного курьера. При этом если смотреть отдельно на каждое конкретное решение - все логично, 3 заказа 3 курьера, даем каждому по 1 заказу. А через 5 минут у нас еще 20 заказов в работе.
Мы решили, что нужно двигаться дальше и писать симулятор пиццерии. Или ДИНАМИЧЕСКИЕ ТЕСТЫ.
Важный дисклеймер - все тесты были полностью навайбкожены. Делали вместе с Сашей, если читаешь - привет.
В чем суть этих тестов - мы берем снепшот пиццерии за какой-то день.
- Заказы, которые создавались, как эти заказы в пиццерии готовили.
- Информация о курьерах, когда пришли на смену, когда ушли, когда ходили на обед и когда возвращались.
- Время в поездке от пиццерии до каждого заказа и между заказами (для того чтобы составить маршрут из 2 или 3 заказов) из Яндекса.
Но Яндекс отдает только время в дороге, поэтому мы сами добавляем некоторое время на то, чтобы курьер поднялся до клиента, спустился, обошел дом и т.д.
И получаем симуляцию пиццерии с некоторыми ограничениями - наши курьеры никогда не опаздывают и всегда приезжают вовремя.
Ну и начинаем создавать заказы, менять их статусы, в определенный момент вызываем продакшен-код реального группировщика, не мок, не фейк, не урезанная версия для тестов, а ровно тот же самый код, который обслуживает пиццерию, и получаем от него ответы в виде групп. Вот это на мой взгляд очень важно, что мы в этих тестах тестируем настояющую боевую систему (она конечно же работает в отдельном контуре)
А затем отправляем курьеров в поездки на эти группы и планируем возврат в пиццерию после завершения доставки. И таким образом воспроизводим день работы пиццерии.
Сейчас у нас воспроизводится 38 пиццериедней - это 15 разных по профилю пиццерий (мало заказов + много курьеров, мало курьеров + много заказов, с плохой кухней, с хорошей кухней) и разные дни (будни, выходные, предпраздничные дни). В сумме у нас получается 4к+ поездок (некоторые из них по 2 или 3 заказа).
По дням все по-разному, есть Георгиевск, в котором 100 заказов и 15 курьеров в сумме за день бывает. А есть Красноярск, в котором 500 заказов и 26 курьеров.
По результатам запуска собираем отчет с метриками, но метриками именно бизнесовыми. Сколько отдали сертификатов за опоздания, сколько заказы лежали после готовки в ожидании доставки, сколько мы доставляли заказы и т.д. А дальше сравниваем две версии группировщика друг с другом по этим метрикам. Профит? Не совсем, но об этом в следующих сериях.
Как я перестал читать логи упавших тестов и начал их видеть
Продолжаем истории про тестирование Умного Трекинга.
Для освежения контекста можно почитать предыдущие посты (раз, два, три)
В предыдущих постах не упомянул ещё один недостаток статичных тестов, который решил с помощью ИИшки. Точнее, упоминал его, но хочется остановиться на нём подробнее.
Нам тяжело было анализировать результаты тестирования. Вот представьте, у вас тест
public async Task RunStandardGroupingScenario(RoutingTestData testData)
{
...
var order1 = new TestOrderBuilder(1)
.PlacedAt(currentDate.AddMinutes(-40))
.WithMeterOffsets(724, 1000)
.Please();
...
await Runner
.WithContext<AutoAssignmentContext>()
.RunScenarioAsync(
...
_ => _.OrderPlacementSteps.GivenOrdersAreOnTheShelf(order1),
...
_ => _.when_GroupOrdersForDelivery_iterate(),
_ => _.then_ORDERS_are_grouped(order1.Number, order2.Number, order3.Number)
);
}WithMeterOffsets. Это смещение заказа от координат пиццерии в метрах. Сделали метод для упрощения написания тестов, чтобы не нужно было искать координаты каждого заказа. Просто указываешь смещение от пиццерии по направлению север-юг и смещение по направлению запад-восток, а тестовый метод сам высчитывает координаты.
И вот перед очередным релизом этот тест падает, и ты видишь буквально:
Orders are not in the same group
Found groups: [{"TravelMode":0,"Orders":[3,2]}], [{"TravelMode":0,"Orders":[1]}]
И что с этим делать? Напомню, что мы тестируем результаты работы алгоритма группировки. Как понять расположение заказов относительно друг друга и пиццерии? Можно, конечно, вспомнить, что первый аргумент в методе WithMeterOffsets — это отклонение по направлению север-юг, но, возможно, и отклонение по направлению запад-восток. Затем мысленно представить себе карту и наложить на неё заказы. Но у меня не получалось.
Что я сделал? Правильно, навайбкодил html, который получал последний запрос к солверу, парсил его и рисовал карту. На карте отмечал маркеры заказов и группы заказов, ну и вообще отображал весь контекст того, какие данные были засетаплены до этого.
Затем сделал генерацию такой карты после каждого теста и приложил её в ТестОпс. Теперь можно легко смотреть на итоги теста, и разбирать упавшие тесты стало сильно легче.
Раньше, без ИИшки, я бы даже не взялся за это, а сейчас в перерывах между тестированием создал вспомогательный инструмент, который плотно засел в тестах. У меня есть ещё один похожий инструмент для других тестов, но о нём расскажу дальше, когда буду рассказывать о динамических тестах в Умном Трекинге.Как автотестируем систему батчинга заказов ч.2
Времени на нормальную отладку тестов у нас не было, мы сразу стали использовать эти тесты для проверки группировок и соответствия системы требованиям. Потому что нам надо было очень быстро тестить гипотезы и мы не могли долго разрабатывать и тестировать. Перед релизом новой версии группировщика запускали тесты, брали упавшие и начинали разбирать. Из инструментов для разбора - только логи системы, мы даже визуально не могли представить где находятся эти заказы. Вот есть координаты пиццерии 30, 31. И у нас есть метод который принимает отклонения в метрах от этих координат, дальше метод сам вычисляет координаты по методу линейного приближения сферических координат. Заказ создается таким образом
var order1 = new TestOrderBuilder(1)
.PlacedAt(currentDate.AddMinutes(-7))
.WithMeterOffsets(-2500, -3000)
.Please();Как автотестируем систему батчинга заказов ч.1
Это продолжение предыдущего поста.
У нас в проекте написаны интеграционные тесты, которые тестируют нашу систему в интеграции - мы поднимаем БД в Docker, запускаем тестовый хост SUT (System Under Test) и запускается Kafka с помощью TestContainers. Но мы не только публикуем события в Kafka но и еще потребялем их. Поднимается отдельный хост с консьюмерами. И тесты проверяют опубликованные события. Ну и 25 фейков внешних зависимостей. В общем-то и все.
В тестах мы сетапим данные, выполняем действий, проверяем результаты. Часть тестов написана на голом nUnit, а часть с помощью LightBDD (из названия следует, что это обертка для описания шагов в тесте в BDD стиле).
Эти тесты проверяют функционал самой кассы доставки: работа с чеками, курьерами, движение заказов, применение группировок.
В общем мы подумали, что наилучшим решением будет писать такие тесты рядом с этими интеграционными тестами, на уже готовой инфраструктуре. НО если все существующие тесты тестировали всю систему в изоляции (кроме перечисленных зависимостей), то у нас появляется внешняя зависимость в виде самого группировщика, который хостится в DataBricks. На самом деле на отдельном эндпоинте хостится Решала (Solver) - который говорит как объединить заказы на основе переданных данных, а логика создания и применения групп на основе его ответов лежит в нашей системе, но для простоты буду называть его группировщик. Мы явно решили ходить из нашей системы во внешнюю потому что целью наших тестов было проверить как группировщик объединит заказы в поездку при определенных условиях.
Вот мы задаем заказы, время их принятия, курьеров, вызываем группировщик - получаем группы и проверяем что группы применились.
Напомню количество переменных которые влияют на группировку:
1. Заказы:
a. Статус;
b. Время от принятия
c. Прогнозное время до конца готовки;
2. Курьеры:
a. Статус;
b. Прогнозное время возращения;
3. Текущая нагрузка на пиццерию;
4. Прогноз спроса в пиццерии;
5. Маршруты:
a. Координаты заказов;
b. Чистое время в пути от Яндекса;
c. Время на сборку заказа (зависит от текущей нагрузки и кол-ва коробок в заказе);
d. Время дойти от пиццерии до машины (у каждой пиццерии разное);
e. Время дойти от каждого заказа до клиента (у каждого заказа разное);
f. Время дойти от машины до пиццерии (у каждой пиццерии разное).
Сначала я написал тесты основываясь на требованиях, а требования для такой системы у нас - двухстраничный документ. Я считаю должно быть минимум 3. 😏
Потом в процессе написания тестов решили, что стоит и дописывать кейсы с реальной пиццерии. Например заметили или пожаловались на кринж группу, мы воспроизводим такой кейс, чтобы убедиться, что проблема действительно ушла.
Таким образом написали 60+ тестов.
И тут начинается самое интересное.
Я в предыдущем посте писал, что у нас было 3 группировщика, которые группировали по разному, поэтому мы подошли к этапу, когда часть тестов не проходила на одном группировщике, часть тестов не проходила на другом группировщике. Как-то мы дошли до того, что у нас был только один группировщик, но сейчас их снова два и у них есть разные версии которые могут работать одновременно на разных пиццериях, плюс у обоих группировщиков есть разная конфигруация работы автоназначения.
Тестирование сложных систем
Я уже рассказывал, что плотно сижу на проекте «Умный трекинг» — это ключевой проект b2b-направления Додо Пиццы. Мы все помним, что он не умный и не трекинг (мы начинаем задумываться о ребрендинге), но это уже мало кого смущает и для простоты буду называть его УТ. Контекст, что такое УТ, вот тут.
Решил рассказать, как мы тестируем его. Поэтому ждите в ближайшее время посты про тестирование УТ.
Итак, погнали.
Первым этапом тестирования являются функциональные автотесты, которые запускаются на каждый коммит. Но это тесты без внешних зависимостей, все зависимости зафейканы (ML-калькуляторы, прогнозы приготовления, гео и т.д.). В этих тестах проверен базовый функционал системы управления доставкой, внутри которой мы создаём свою систему батчинга. В базовый функционал входит получение оффера на заказ курьером, формирование групп, отказ от оффера, принятие оффера и т.д.
Как работает группировка
Автотестов, которые проверяют бизнес-требования группировки, не было. И вот тут начиналось ручное тестирование. Базово УТ работал так - мы каждые 30 секунд запускаем итерацию УТ, плюс эти итерации запускаются при различных триггерах, например когда заказ упаковали или когда появился новый курьер. На то, как будет сформирована группа влияет что-то в районе 10 показателей, которые меняются прям на ходу. Прошло 1, 2, 5 минут, группы уже будут другими. Появился или исчез курьер - группы будут другими. Появился новый заказ - думаю вы поняли логику. Все эти показатели основываются на штрафах и бонусах. Задача группировщика найти такой вариант группировки, где суммарный штраф минимален (это очень упрощенное объяснение). Внимание вопрос, как я, ручной тестировщик, создавший на тестовом стенде 5-10 заказов, могу посчитать штрафы всех заказов по всем показателям (учитывая что есть штрафы которые меняются каждую минуту)? Сам пересчет и запрос к группировщику запускается каждые 30 секунд. Это невозможно.
Для понимания масштаба проблемы предлагаю вам прочитать недавнюю статью на хабре про алгоритмы в лифтах (просили кого-то на собесе протестировать лифт?). Вот у нас примерно тоже самое, только подвижных частей - больше.
Как мы тестировали требования
Мы проверяли основные требования. Что соседние заказы должны объединяться, заказы в разные стороны не должны группироваться, принятые заказы не должны группироваться с готовыми и т.д. Но даже тут были проблемы — заказы, по которым должны быть выданы сертификаты на пиццу. Чтобы заказ был близок к сертификату (чем ближе тем больше штраф), тебе либо нужно идти в БД сервиса и руками менять время принятия заказа, чтобы система посчитала его просроченным или близким к просрочке (но тогда данные могут разъехаться, если забыть поменять значение в какой-то другой таблице или базе), или сидеть ждать почти час, пока заказ просрочится. Ну и конечно же в таком режиме мы не могли не пропускать баги. Например, был прикол — решили реализовать требование не группировать заказы, угол между которыми больше 120 градусов (в основании угла пиццерия). Создали заказы, посмотрели, что пары заказов с таким углом не группируются. Я специально выделил слово «пары», потому что на проде тройки заказов группировались и на 180 градусов. Между 1-м и 2-м заказом 70°, между 2-м и 3-м — 90°. А между 1-м и 3-м — 160°. Ну и ещё заодно проверяли, что техническая интеграция всех систем прошла успешно.
Какие выводы я сделал
А вывод такой, что ручное тестирование таких комбинаторных систем - то еще приключение. Сколько бы ты не тестировал, все равно не сможешь провести исчерпывающее тестирование. И из этого следует простая и очевидная мысль - надо навалить автотестов на это дело.
В следующем посте расскажу как мы это дело автоматизировали и что из этого вышло.
Хотели бы вы найти багулю в самолёте? Я если честно не очень. Вот @DanilBabich нашел, порадуемся за него, что хотя бы не крит баг 😬
Если хотите заебать утомить соседа своими выходками, то вы сели в правильный самолёт 😏
Если вдруг вам интересно погрузиться немного в дизайн вещей, которые вас окружают, то можно почитать The Design of Everyday Things (в русском переводе Дизайн привычных вещей). Не так давно узнал об этой книге на уроках английского. Еще не читал, но отзывы на амазоне внушают оптимизм.
Погружайтесь в бизнес
Почти всю прошлую неделю я провел в пиццериях своего города. К нам наконец докатился проект Умный Трекинг. Я сразу же пошел смотреть как им пользуются.
Что такое Умный трекинг (УТ)
Напомню, что УТ - это система батчинга заказов на доставку. Такие есть или должны быть у всех агрегаторов и служб доставки. А так как Додо пицца развивает свою доставку, нам тоже такая нужна.
Сейчас курьеры сами набирают себе заказы, а вообще не должны. Представьте если бы водители в Яндекс Такси видели весь список заказов и выбирали бы кого они повезут и в каком порядке. Посмотрел бы я как вы уедете из какой-нибудь деревни.
Что узнал
Пока я наблюдал за работой системы и курьеров, я выяснил несколько схем обхода нашей системы.
1. Курьеры в моем городе привыкли возить по 2-3 заказа, поэтому они совершают некоторые манипуляции, чтобы система отдавала им группы по 2-3 заказа, даже если в моменте система считает что нужно съездить на один заказ. Они искусственно снижают количество доступных курьеров для системы и получают более плотные группы.
2. Курьеры используют лазейку, которую мы оставили, чтобы не везти заказы в строгом порядке. Помечают первый заказ который не по пути проблемным и им открывается возможность развозить остальные заказы.
Теперь мы будем считать количество этих событий и знать, что в пиццериях с аномально большим количеством этих событий - фродят. Значит мы не можем полагаться на метрики этой пиццерии и делать выводы о качестве работы нашей системы.
А еще я заметил, что курьеры ооооооочень долго собираются на заказ. Недавно еще внедрили новый функционал сбора на заказ из-за чего время могло вырасти. Так вот мы в своей системе закладываем 2 минуты на сборку, а среднее время которое тратят - 7 минут. Поэтому наша система более оптимистична настроена и может отправить курьера на 3 заказа с учетом сбора 2 минуты, а из-за того что курьер собирается 7 минут, можем на последний заказ не успеть. Если бы система знала что курьер будет собираться 7 минут, то мы бы отправили только 2 заказа. Теперь задача на анализ времени сборки заказа ушла в команду аналитики и по результатам будем принимать какие-то меры.
Также услышал что думают о разрабатываемой системе курьеры. Пришел курьер на работу, хотел взять 2 или 3 заказа, но нагрузка на пиццерию - минимальная. Мы предлагаем ему отвезти 1 заказ, он выдает обратную связь: "Что за хуйню вы сделали?". В другой пиццерии сказали что наша система "шляпа". 😏
К чему я это все, как вы считаете, узнал бы я об этом сидя в офисе? Думаю ответ очевиден, не узнал бы. Поэтому, если вы в работе автоматизируете реальный бизнес и у вас есть возможность наблюдать за тем как пользуются вашим софтом (удаленно или на месте) или хотя бы если вы можете сами попользоваться этим софтом (но тут тоже может быть искажение, вы знаете как он работает его логику и она может казаться вам даже вполне хорошой, но ваши пользователи не знают и не должны знать, поэтому этот подход не так хорош), то вам прям категорически, прям катастрофически нужно это делать. Пойдет и то, если вы будете пользоваться своим продуктом. Под шумок напоминаю вам, что у меня по этому поводу есть старая статья на хабре, которая между тем не потеряла своей актуальности.
Чюваки запилили топовую визуализацию карты телеграмм каналов. Близкие по тематике каналы собираются в кластер. Нашел себя в кластере QA но чуть в сторонке. Воспринимаю это как то, что у меня канал с особенностями😏
Заходите позалипайте, мне понравилось.
+1
Allure TestOps MCP
А вы знали, что есть MCP сервер для работы с TestOps?
Помните я ныл что в Allure для .NET не работает плагин для бронирования AllureID, разработчики обещали починить, чинили чинили, да не починили. По крайней мере когда я последний раз пытался - не работал.
Чтобы вы понимали уровень боли:
Наши разработчики в компании делали в GitHubActions отдельные дожбы, которые получают AllureID (на 1 скрине) 🤯
Использовали http-клиент в Rider, прихранивали в репозитории проекта .http файл, куда нужно было подставить api ключ от TestOps, который выполнит http-запрос, описанный в файле. Суть запроса - сходить в API TestOps, получит AllureID и вернуть его 🤯🤯
Но теперь это нахрен не упало, ни плагин, ни клиенты, ни джобы. Продуктовая стратегия разработчиков TestOps "подождем пока проблема как нибудь сама рассосется" сработала. Теперь за вас все будут делать роботы (если вы конечно пользуетесь агентами для написания кода). Спасибо хорошему человеку, которые сделал это 🙏
MCP дает возможность работать с тест кейсами, создавать тест кейс и возвращать его AllureID, работать с запусками, степами, кастомными полями, проектами и много чего еще.
Мне очень удобно. Можно добавить правило в свой агент, чтобы при написании нового теста он сам ходил и добавлял AllureID, либо просить его сделать это.
Я регулярно пользуюсь для проставления AllureID, поиска дубликатов и методов где AllureID отсутствует.
Короче если вы работаете с агентами и TestOps - эта штука для вас обязательна к ознакомлению.
Традиционные итоги года канала. Можно сравнить с предыдущим годом
Если коротко, то текущий год не такой успешный как предыдущий.
Самый популярный пост про вакансию🤷♂️
В следующем году буду исправлять ситуацию.
Предлагаю сделать упражнение - накидывайте в комменты свои итоги года, чтобы осознать какие вы молодцы❤️
Кто-то забыл протестить карусель с изображениями 😏
А что творится в горзонтальной ориентации, лучше вообще не видеть 🩸 (закину видос в комменты)
Решил поныть рассказать о том, над чем сейчас работаю и с какими сложностями столкнулся.
Моя команда взяла в разработку проект по батчингу (группировке) заказов на доставку.
Есть курьеры и есть заказы, которые нужно развезти как можно быстрее, но при этом не очень долго (в рамках 60 минут чтобы не отдать сертификат) при доступном наборе курьеров. А от меня как тестировщика этого функционала ждут, что я протестирую качество группировки до того как мы выйдем на реальную пиццерию.
Казалось бы задача не сложная, подавай на вход курьеров и заказы с адресами, получай на выходе батчи и назначай на курьеров. Но есть нюансы бизнес-ограничения, нельзя возить заказ в разные стороны (хотя я считаю это плохим ограничением), у заказов есть разные статусы, от которых тоже зависит возможность объединения. Например готовый заказ не долежн ждать не готовый. Но не всегда, иногда должен подождать. А кроме этого мы можем придержать заказ и не показывать его если нет свободных курьеров, которые его повезут. Есть прогнозное время приготовления заказов (со своими приколами), которое тоже влияет на то, можно ли применить получившуюся группу.
У курьеров тоже не все так гладко, есть курьеры которые находятся в пиццерии, а есть курьеры которые едут с заказами и вернутся в пиццерию через Х минут. А этот Х минут - это прогноз, который не всегда точен. А еще есть максимальная вместимость курьера, когда он не может взять больше 3 заказов (хотя возможно справедливее тут считать в коробках, но не суть). А еще ест разные типы курьеров, пеший, вело, авто. А еще есть настройки пиццерии, которые у каждой уникальные, например сервисное вермя, которое курьер тратит на каждую поездку - дойти от пиццерии до машины и обратно, а также сервисное время на каждый заказ - дойти от машины до клиента и обратно.
Все осложняется тем, что прямо сейчас разработаны и проверяются 3 разных инструмента для группировки заказов. Все они принимают отличающийся набор данных и в итоге по разному группируют 🤯
Изменение любого из этих параметров-ограничений на минимальное значение может кардинально изменить группировку.
И мне нужно протестировать это и написать интеграционные автотесты, которые проверяют качество группировки. Тесты то написать не проблема (на самом деле некоторый набор уже написан), но нужно написать тесты которые отражают реальное поведение, а не синтетические кейсы, которых на проде практически не встречается (такие тоже написаны) и еще желательно не раздувать сьют, чтобы он проходил за вменяемое время, если мы хотим это встроить в пайплайн.
В общем как-то так, ничего не понятно, но очень интересно.
Вчера опять возил пиццу в пиццерии и тестировал приложение для курьеров. Нашел 14 багов и моментов которые можно улучшить. Все найденные бриллианты отнес команде разработки.
Вот вам веселый скрин. Как думаете сколько кнопок на которые можно нажать изображены на картинке?
+1
Уверен, в жизни каждого тестировщика рано или поздно случается встреча с автотестом, который ничего не тестирует или тестирует не то что заявлено или вообще ничего не проверяет. Сегодняшняя история как раз об этом.
Среди всех написанных у нас UI автотестов, есть автотесты и на интерфейс операторов Контактного Центра для приема и редактирования заказов.
Один из тестов проверяет, что при постановке какого-либо ингредиента в стоп-лист - этот продукт в интерфейсе становится недоступен к заказу.
Визуально это выглядит так, что в карточке продукта, который возможно заказать, вариации (размеры Маленькая, Средняя, Большая и т.д.) продукта имеет обычный вид и css класс
product__label, а в карточке продукта, который невозможно заказать, в вариациях продукта меняется цвет текста и CSS класс становится label.stop.
Есть Assert который проверяет что на странице должен быть хотя бы один элемент с классом label.stop. Если его нет на странице, то кидаем исключение.
Разбирая этот тест, мы заметили, что в стоп-лист ставится ингредиент которого нет в составе продукта, который должен стать недоступным к заказу. А суть стоп-листа в том, что если вы ставите добавляете в него ингредиент, то невозможно заказать ни один продукт в составе которого есть этот ингредиент. Получается парадокс. В стоп-листе ингредиент которого нет в продукте и продукт доступен для заказа, но при этом тест который проверяет что продукт недоступен к заказу успешно проходит.🤣 Этот метод написан в 2018 году и в этой части не менялся😂
Если присмотреться повнимательней, то видно что Assert находится внутри foreach - который проходи по всей коллекции элементов label.stop и проверяет что вся коллекция больше 0. Это вообще странный цикл, но не в этом суть. А суть в том, что если коллекция пустая, а в нашем случае она очевидно пустая, потому что продукт не в стопе, то тест даже не заходит внутрь цикла и не выполняет проверка и завершается успехом. Как вам такое? 😏
Делитесь какие вы не работающие проверки находили в своих тестах, будем смеяться вместе.Уверен, в жизни каждого тестировщика рано или поздно встречается автотест, который ничего не тестирует или тестирует не то что заявлено или вообще ничего не проверяет. Сегодняшняя история как раз об этом.
Среди всех написанных у нас UI автотестов, есть автотесты и на интерфейс операторов Контактного Центра для приема и редактирования заказов.
Один из тестов проверяет, что при постановке какого-либо ингредиента в стоп-лист - этот продукт в интерфейсе становится невозможно заказать.
Визуально это выглядит так, что в карточке продукта, который возможно заказать, вариации (размеры - Маленькая, Средняя, ТСредняя и т.д.) продукта имеют обычный вид и css класс
product__label, а в карточке продукта, который невозможно заказать, в вариациях продукта меняется цвет текста и css класс становится label.stop.
Есть Assert который проверяет что на странице должен быть хотя бы один элемент с классом label.stop. Если его нет на странице, то кидаем ошибку.
Разбирая этот тест, мы заметили, что в стоп ставится ингредиент которого нет в составе продукта который должен стать недоступен к продаже. А суть стоп-листа в том, что если вы ставите ингредиент в стоп-лист, то невозможно заказать никакой продукт в составе которого есть этот ингредиент. Получается парадокс. В стоп-листе ингредиент которого нет в продукте и продукт доступен к заказу, но при этом тест который проверяет что продукт нельзя заказать успешно проходит.🤣 Этот метод написан и не изменялся с 2018 года.😂
Если присмотреться повнимательней, то видно что Assert находится внутри foreach - который проходи по всей коллекции элементов label.stop и в зависимости от размера коллекции проверяет что вся коллекция больше 0. Это вообще странный цикл, но не в этом суть. А суть в том, что если коллекция пустая, а в нашем случае она очевидно пустая, потому что продукт не в стопе, то тест даже не заходит внутрь цикла и не выполняет проверка и завершается успехом. Как вам такое?
Делитесь какие вы не работающие проверки находили в своих тестах?
Вчера узнал о фиче в Хроме - command pallet. Через которую можно вызвать всякие команды. На самом деле много в каких инструментах она есть, но что она есть в Хроме я не знал.
Открываете консоль разработчика и на маке жмете cmd + shift + p (на винде скорее всего ctrl + shift + p) и вводите примерное или точное имя команды которая вам нужна - профит. Не нужно больше копаться в настройках, менюшках.
Как я нашел ее - мне нужно было сделать скриншот всей страницы, когда вся страница на экран не помещается. В Андроиде есть такая фича - очень удобно. Я пошел искать как это сделать и нашел путь через командную панель. Сделать скриншот всей страницы - "Capture full size screenshot" если что.
Запись в доках Chrome Dev Tools о командной панели опубликована в апреле 2019 года
Давайте посмотрим кого больше, ставь
🤯 - если не знал про командную панель
🙄 - если знал про командную панель
Вопрос знатокам. Если летящему ребенку один год и 10 месяцев, какой счетчик увеличить?
Тестировщикам Аэрофлота - привет👋
UPD. В комментах рассказали, что если Младенцу нужно отдельное место, то увеличиваем счетчик Дети, а если не нужно - Младенцы 😬
Продолжение истории с Хабром
В комментах под предыдущим постом, я написал что техподдержка ответила на отвали. Но был не прав, исправляюсь. Мы продолжили общение и возможно даже нашли проблему.
Проблема связана с обложкой статьи. Я изначально прикрепил картинку не подходящего размера (и в пикселях и в МБ). Затем добавил картинку подходящую по требованиям, но она не перезаписалась на сервере и поэтому я не мог сохранить статью. Чтобы это выяснить - я отправлял им Google Doc в котором была статья из которого я копировал текст в их редактор.
Лайк техподу Хабра за работу ❤️
