Вайб кодинг и вайб тестинг — полный гайд на реальных проектах в Cursor AI и ChatGPT

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

На данный момент курсор является самой популярной программой для вайп-кодинга, потому что он невероятно удобен, под капотом содержит огромное количество фич, и многие тренды и вайп-кодинги задал именно он. Но этот гайд вы сможете применять к любой другой программе для вайп-кодинга. И неважно, будут ли это программы по типу курсора Coder Try или Google Anтиv, либо это будут так называемые инструменты командной строки, типа Cloud CД от Антропика или кодекс от Open AI.

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

А во второй части видео мы довольно глубоко рассмотрим тему вайп-тестинга. Я покажу вам разные хитрые правила: промпты, MCP сервера, родмапы, при помощи которых курсоры будут писать тесткейсы. А по этим тесткейсам автотесты. Мы рассмотрим немного тему тесткейсов и автотестов под веб при помощи курсора. И также я вам на реальном проекте в текущей компании, где я работаю, покажу, как на основе свагера я создаю тесткейсы на API при помощи курсора, а потом по ним прошу курсор написать десятки и сотни автотестов буквально одним нажатием кнопки.

И, конечно же, мы не обойдём стороной наше любимое ручное тестирование. И при помощи нашего с вами любимого чаго-либо ТЗ, без макетов на реальном проекте мы найдём всю необходимую документацию. По этой документации мы напишем качественные чек-листы. И по этим чек-листам мы напишем качественные тесткейсы. Погнали.

Итак, курсор можно скачать с сайта.com. Здесь можно перейти на вкладку pricing и увидеть, какие есть тарифы у курсора. Я использую на данный момент вот этот тариф за 20 баксов в месяц, но сразу скажу, при активном вайп-кодинге он очень быстро уходит. Мы на вкладке download можем скачать курсор под различные версии. Я это делать не буду, там всё просто. Вы скачиваете, нажимаете далее, далее, и курсор у вас устанавливается.

Теперь мы закроем браузер, чтобы он нам не мешал, и откроем курсор. Вот он у меня открыт курсор. Здесь я создал папочку пустую, назвал её тест. И давайте мы откроем через курсор вот эту вот папочку. Вот так вот выглядит стандартный вид курсора. У нас здесь есть вкладочка Agents и есть вкладочка. Когда мы нажимаем на вкладочку, мы попадаем в стандартное окно, которое присутствует во всех средах разработки, в разных текстовых редакторах под разработку, где слева у нас дерево с кодом, а справа у нас будет сам код. Если вы когда-либо работали с редактором VS-код, вот давайте я его открою, чтобы вы посмотрели. Вот примерно вот так вот он выглядит. То есть вот тут дерево, вот тут код, то курсор выглядит точно так же. И курсор, как и многие другие редакторы кода на основе EИ, они все построены на основе VS-кода. Поэтому, если вы работаете с заработали с ВС-кодом, то с курсором вам будет работать привычно.

Здесь мы можем переключиться на вкладочку Agents, и у нас откроется курсор в режиме агента. Наверняка вы эти окна много раз видели, если пользовались чат GPT, если пользовались Perplexity и другими и агентами. Давайте перейдём сейчас в настройки курсора. Вот здесь мы нажимаем на шестерёнку и переходим в настройки курсора и быстренько по ним пробежимся.

Вкладка General. Здесь основные такие настройки, они стандартные, как и во всех других программах. Здесь можем настроить разные шрифты, темы, дефолтные лейауты. это либо agent, различные другие настройки. Можем настроить импорт из VS-кода, если вы в нём работали. В целом, ничего здесь такого интересного нет. Здесь можно нажать на Open. И мы переходим на наш аккаунт в курсоре, где мы можем посмотреть тоже различные штуки, аналитику использования, сколько у нас уже токенов потрачено и так далее.

Давайте теперь перейдём на вкладку Agents. И на вкладке Agents мы можем выбрать default mode. Это значит, что у нас будет появляться по дефолту agent или plan или ask. Давайте я покажу. Вот если мы переключимся на вкладку agent. И вот здесь мы можем выбрать либо plan, либо Ask, либо agent. И вот как раз вот эта вот настройка, она отвечает за то, какой режим агента будет показываться. Можем выбрать default location, можем выбрать размер. Maxpunt означает, что мы можем открыть не больше шести вкладок с и агентами. В целом это количество оптимальное. Давайте я вам продемонстрирую. Нам нужно нажать вот сюда i pain. У нас открывается вот так вот окно чата с иагентом. И мы можем вот здесь вот плюсиком 1 2 3 4 5 6 и видите, больше шести оно нам не даёт. создать. Нас в целом устраивает. Здесь вот я рекомендую в usage summary поставить always. После того, как вы это сделаете, у вас будет видно. Давайте мы переключимся на вкладку Agent. И мы здесь видим, что мы использовали сейчас 50% от нашего платного лимита.

Переключимся обратно на вкладку Agents. Вот здесь в автоun. Особенно если вы ещё новичок в использовании курсора, я вам рекомендую вот поставить такую настройку ask every time. Что это значит? Это значит, что курсор вас будет каждый раз спрашивать разрешение, чтобы выполнить код, чтобы открыть терминал, выполнить какую-то команду и так далее. Я рекомендую пока что оставить вот эту настройку и убрать flк с браузеer Protection, чтобы у вас каждый раз не спрашивало разрешение открыть браузер, так как вы, ну, реально устанете каждый раз давать разрешение. Поэтому я рекомендую эту галочку оставить выключенной. Также я рекомендую вот эту вот галочку WebSarch Tool тоже оставить включенной. Эта настройка позволяет искать курсору что-то в интернете.

На вкладке Tab настройки у меня вот такие. Я рекомендую оставить те же самые настройки. Дальше мы переключаемся на вкладку модели. И здесь мы можем выбрать различные модели, которые у нас будут показываться вот здесь. То есть, видите, по дефолту у меня выбран Sonet 4 и 5. И вот здесь есть различные модели. Также мы можем провалиться во все модели и включить какие-то ещё определённые. Вот, как мы видим, здесь у нас есть разные другие модели. Вот что-то типа Грока, модель от Илона Маска. И, допустим, мы хотим пользоваться ей, мы можем её здесь включить, и она у нас будет доступна. Также мы можем добавить какую-то свою кастомную модель. Можем также воспользоваться IP ключами и подключиться к какой-то штуке типа Open Router, который интегрирует все модели, вставить свой APK и использовать модели через Open Router.

Дальше мы переключаемся на Cloud Agents. Здесь ничего, в принципе, интересного нет. Дальше мы переключимся в Tools и в MCP. Вот здесь у меня по дефолту сейчас выключены три MCP, с которыми мы будем работать. Это Sequential Sying, это Playri и Chrome def Tools. MCP - это модельный контекстный протокол, который был представлен компанией Antropic, которая, в свою очередь, создала Cloud Code и другую линейку модели от Cloud. Это, по сути, стандарт, который упрощает интеграцию больших моделей языка с внешними системами данных и инструментами.

Первый MCP, который мы рассмотрим, и, пожалуй, самый популярный у вайпкодеров - это Sequential Sinking. Это MCP плагин от Antropic, предназначенный для улучшения многосценарного мышления модели. Он позволяет курсору делить сложную задачу на последовательные шаги, выполнять промежуточные вычисления, хранить контекст и объединять результаты. Он включается только в тех случаях, когда запрос действительно требует пошаговое рассуждение или планирование.

Следующий MCP, который мы рассмотрим - это Chrome def Tools MCP. Этот MCP-сервер интегрируется с Chrome de Tools протокол. Он даёт курсор низк уровневый доступ к дом, к сети, консоли, JS, контексту. Он считывает HTML-структуру, наворы запросы, cookies, local storage. Позволяет инспектировать элементы, менять дом, ловить ошибки JS. может использоваться для дебага, оптимизации, анализа производительности и просмотра кода страницы.

Следующим плагином, я надеюсь, я вас скоро удивлю, и это PlayRIDs. Это MCP плагин для автоматизации браузера и UI-тестов. Он позволяет модели писать и выполнять playрай скрипты прямо из курсор. MCV Play открывает сайты, кликает кнопки, вводит текст, проверяет наличие элементов, текстов и состояний, может генерировать полноценные end to тесты или выполнять шаги тестирования. И это я вам скоро продемонстрирую.

Дальше мы переключаемся в рулсы и команды. Здесь у меня пока никаких правил не задано, но, естественно, мы в будущем это исправим. У нас будут здесь различные правила. Ну давайте пока поговорим, что же это такое. Что такое user rules? User rules - это, по сути, твои личные правила, которые применяются только для тебя во всех чатах курсора. Ты можешь задать тон, общий стиль общения, какие-то ограничения, которые будут работать именно только для тебя.

Дальше, что такое Project Rules? Это правила, которые создаются внутри конкретного проекта. Допустим, у меня есть проект с автотестами, и я хочу, чтобы для этого проекта все, кто использует этот проект, действовали какие-то определённые правила по стандарту автотестирования, по разметке и так далее, и так далее, и так далее.

Также у нас есть команды Team Command, Project Commands и User Command. Что это такое? Это так называемые промпт-шаблоны, которые можно вызывать прямо в курсор. Условно можно задать какую-то команду, допустим, step и прописать, что в степах всегда декомпозируй задачу на мелкие кусочки. И аргументом будет название задачи. И условно, если у нас такой степ будет прописан, то мы можем вызвать степ через собачку и дальше прописать, что именно я хочу сделать. Но об этом мы тоже обязательно ещё поговорим.

Давайте дальше переключимся на вкладку indexсиing и docs. Из интересного здесь мы можем добавить какую-то опишку на какую-то доку, и курсор будет на эту опишку ориентироваться.

И теперь я немножечко буквально затрону тему плагинов. Если вы пользуетесь ВС-кодом, то вс-коде есть различные плагины, которые можно поставить и с которыми будет гораздо удобнее работать со средой разработки. То же самое есть и в курсоре. Здесь я буквально расскажу, вот у меня, видите, много плагинов разных поставлено, но я расскажу буквально про два. Это плагин Project Manager, вот он так и называется, Project Manager, где я, если этот плагин поставлю, у меня появляется вот такая вот вкладочка. И вот на этой вкладочке я могу переключаться на различные проекты. То есть по дефолту, если этого плагина нет, то нужно каждый раз вот через файл, через Open открывать новый проект, и это очень неудобно. А через этот плагин я могу переходить в любой проект. Перешёл в этот проект, перешёл вот в каталог 4те тест проект. И вот этим он и удобен.

И следующий плагин, про который я хочу рассказать, он называется Git Lens. Вот так вот он пишется. Видите, он у меня установлен. И после того, как вы его поставите, к примеру, я переключусь на base. Java и, допустим, наведу вот на эту строчку. Видите, у меня показывается информация, что такой-то вот человек, вот я запушил такие-то правки, такой-то был комит. В общем, вся информация о том, когда у нас был сделан комит, push по конкретной строчке, по конкретному файлу и так далее.

Теперь давайте вернёмся в наш тестовый проект. Нажимаем Open. Вот он тест. Откроем его и будем работать с ним. Давайте мы переключимся теперь в режим agents, который наверняка многим будет более привычен, и поработаем вот с этими режимами. Давайте переключимся в режим Ask и спросим. у курсора. Сможет сможешь ли ты создать игру Арканойд? Все наверняка и в неё в детстве играли. И курсор мне сейчас напишет, сможет ли он это сделать, даст какую-то дополнительную инфу. Вот видите, он мне уже в целом эту игру создаёт. Давайте я остановлю это безобразие, нажму на стоп.

И давайте теперь и мы поработаем с режимом план. Теперь спросим то же самое. Теперь в режиме план мы курсору напишем: "Создай нам браузерную браузерную игру Аркаid." И нажимаем Enter. И смотрите, сейчас он нам составит конкретный план, спросит какие-то нюансы. Вот asking question. Мы ждём, когда он подготовит вопросы. И он спрашивает: "Какой стек технологии вы предпочитаете?" Я напишу: "Окей, чисто HTML CS JavaScript. О'кей, базовая версия". Дальше нажимаю continue. Какие функции должны быть в игре? И всё, он создаёт план. И после этого, когда он этот план создаст, я смогу это выполнить. Но мы сейчас делать это не будем, так как я просто вам показываю для примера. И с планом всё-таки он создаёт игру немножечко подольше.

Вот поэтому давайте я вообще просто почищу вот этот чат и напишу. Вот закрою эту вкладочку вот план MD. Так, да, у меня папочка пустая. И в режиме снова агента просто снова попрошу его создать браузерную игру. Создай мне браузерно arканоid. Arcanoid, да. Нажимаем Enter. В режиме агента используем SN 45. И всё. И давайте посмотрим, какую он нам игру создаст. создаётся что структуру, добавляет CSS, реализовывает игровую логику. Ждём. Можем переключиться в режим. Видите, он нам уже создал файл IND HTML. Ждём, когда он создаст нам CSS. Дальше он должен создать, по сути, JS-файл, чтобы именно запрогать логику игры. А мы в этот момент ждём. Он нам предлагает открыть эту игру в браузере и протестировать. О'кей, давайте нажмём на Run. И смотрите, у нас открылась в браузере игра. Нажимаем начать игру. И видите, вот такой вот органоид, уровни, видите, счёт и так далее. Мы можем, в принципе, скопировать вот этот вот local host, открыть браузер и открыть игру. вот тут начать и играть в эту игру браузере. Вот так вот в неё можно интересно играть. Такая симпатичная игра.

И теперь смотрите, давайте создадим нового агента. Вот здесь новый чат. И давайте попробуем сделать так. Мы создадим здесь два файлика. Один файлик назовём код Review. Код revw. result result md и создаём бапортре md отлично создали так здесь он у нас закончил пол всё а в этом чате давайте мы напишем так ты senньорor front and developer сделай код review этой игры и результаты напиши в файле файле и укажем файл код revwmd. Вот. Отлично. Давайте это сделаем. Давайте я прежде чем это делать, я переключусь на другого агента. В принципе, это делать не обязательно, но я, когда вайпкожу какие-то проекты, у меня всегда вайпкодит один агент, а ревю я прошу делать другого агента. И давайте здесь сделаем точно так же. Давайте попросим чат GP 5 проревьюить наш нашу игру, наш код. Погнали.

Итак, как мы видим, Senior FREN Developer у нас закончил кодрев нашей игры. Мы можем увидеть результат. Давайте сразу откроем review result. Нажмём п и посмотрим, что же он нам нашёл. И он нам нашёл, мы видим, разные ошибки. Написал, что чисто структуры, понятно, разделение, бла-бла-бла. Написал критичное замечание. Масштабированный канвас сломает управление мышью. Предложил быстрый фикс. Дальше коллизии с кирпичами. Тоже показал нам какой-то код. Минимальный вариант, видимо, который нужно выбрать. Ещё тут нашёл какие-то ошибки. Мыльный рендер и так далее. Семантика в целом корректная. Рекомендации по доступности. В общем, нашёл какой-то пул ошибок, и он нам предлагает сразу внести эти фиксы в код. Давайте это сделаем. Давайте так и напишем. Да, внеси эти фиксы. в код. Теперь снова немножечко подождём.

Итак, Front Developer закончил свою работу и исправил все ошибки. Вот он нам даже составил туду лист, в котором указалось, что он исправил, написал какую-то информацию, указал, что у нас все правки. и так далее. О'кей, давайте примем все эти изменения. Пол. Давайте на всякий случай откроем ещё раз наш нашу игру и посмотрим, что она также работает, что здесь в целом всё то же самое. Ну, о'кей. Визуально вроде бы всё работает.

Теперь давайте в этом же окне попробуем протестировать нашу игру. Напишем выступи в роли сниженер и протестируй эту игру. Все баги. Зафиксируй в файле бак бакрепорт MD. Так, теперь мы снова ждём.

Итак, чат же GP 51 у меня подвиз. В итоге я остановил процесс, выбрал другую модель Композер. Это модель от самого курсора по разным тестам. Она сейчас считается самой быстрой. И в итоге я перезапустил процесс, и композер очень быстро мне отработал и нашёл следующие баги. Неправильная чистка канвас после HDP масштабирования. Описал шаги. Наблюдать за трисовкой. Давайте всё примем, посмотрим. Код проблемы. Использовать проверку и пересечения. Мяч может застрять в платформе при определённых углах. Прикольно. Платформа под очень острым углом или снизу он может застрять внутри платформы, многократно оттаскивая и теряя жизнь. Ишка мне реально нашла много различных багов, проставила приоритет, статус, серьёзность, описала заголовки в целом по таким канонам заведения бакрепорта. Вот. О'кей.

Теперь давайте в этом же контексте тоже использовая и модель композера. напишем. А теперь выступи выступив в роли в роли Senor Front and Developer и по фиксе. И тут мы видим тоже, что он нам написал отчёт, что именно нашёл. краткое такое sumary, что два критических бага, три серьёзных, пять средних, четыре улучшения и каждый баг включает в себя приоритетны серьёзно шаги воспроизведения, ожидаемый фактическое поведение, проблемный код и рекомендации по исправлению. И по и по фиксе. Ну да, отправил случайно. Ну о'кей. Я сейчас надеюсь, что он всё пофиксит. Также пусть это сделает яишком. от курсора. Уверен, что она сделает это быстро. Так, и Ишка дала мне отчёт, что исправлены критические баги, серьёзные, средние, и написала, что все изменения протестированы, ошибок линтера нет, игра готова к использованию. Окей, примем эти изменения. Давайте снова откроем игру, пробуем в неё поиграть. визуально как будто всё так же работает, как и работает.

А сейчас с вами мы поговорим, как создавать действительно качественные, многофункциональные, продуманные по дизайну мобильные приложения, веб-приложения, САС и так далее. Сейчас я вам покажу такой инструмент, как lavable, и мы сравним немного, как он работает с курсором. В чём вообще разница между Lavable и курсором? Lavable - это такой iбиilderдер, обученный на UI паттернах и лучших практиках дизайна сайтов. Анимации, отступы, визуальный баланс. Он понимает запрос вроде сделай минималистичный лендинг для стартапа и генерирует такой композиционно-правильный визуально сбалансированный макет часто сразу с адаптивом. Курсор - это, по сути, такой инженерный агент, который пишет чистый код по правилам. Да, он знает Win, React, JS и прочие модные мобильные frontend-фреймворки, но как бы не чувствует дизайна, если ты не задашь курсору конкретные визуальные референсы. Что мы с вами в целом и сделаем.

Вначале мы зайдём в настройки и убедимся, что у меня ничего не установлено. Из русов у меня установлено только моё системное правило. из MCP у меня никакое MCP не установлено и всё, больше ничего нет. И давайте мы попробуем курсору задать вот такой вот промт. Сделай современный веб-сайт приложения mail Mind. Нужны страницы, главный дэшборд, план на неделю, рецепты, список покупок, профиль, настройки, дизайн, минимализм, премиальный вид, много воздуха, мягкие градиенты, карточки, аккуратные тени, адатибна, хорошая типографика, светлая тёмная тема. на странице сделали реалистичные блоки и демоданные без внешних картинок. То есть вот такое вот средненькое ТЗ, да, в целом мы многое прописали. И давайте мы попробуем дать такой вот ТЗ курсору и посмотрим, что он у нас сделает. Sonet 45 агент. Погнали. Сейчас мы ждём. Сейчас делает нам вот эту вот вебапку. Посмотрим, как она будет выглядеть.

Так, курсор закончил. Теперь он просит запустить приложение для проверки. Делаем это. Так, у нас открывается сайт. Давайте мы его откроем в отдельном браузере. И смотрите, вот так вот выглядит продукт, который напилил курсор. Ну, кстати, создать план не работает. Дашборд. Начать готовить список покупок. Так. Ага. Ну, в общем, вот так примерно выглядит. Тему можно поменять. В целом, на самом деле, неплохо. Я думал, будет хуже. А теперь давайте попробуем вот то же самое один в один. Всё, он нам написал, что приложение запущено и так далее. Вот здесь оно оно у нас открыто в мобильной версии. Вот мы закроем консоль. И вот в целом, да, в мобильной версии тоже выглядит оно вполне неплохо. Теперь мы попробуем вот этот же промт. Вот его скопируем и создадим в lavable. Вот абсолютно то же самое. И давайте посмотрим, что нам сделает Lavable. Ждём.

Мы наконец дождались. И смотрите, что нам сделал Lavable. Мы видим менюшку, мы видим различные компоненты, красивые иконки, прогрессбары, план на неделю, календарь, рецепты, обеды, ужины, профиль. Ну, то есть смотрите, по визуалу, согласитесь, давайте даже вот выйти из аккаунта, но кнопка некликабельна. По визуалу выглядит очень-очень даже красиво. Вот давайте, если мы сравним, что нам сделал курсор чистый, ну и как бы, согласитесь, гораздо хуже. Тоже он нам сделал рецепты без картинок, без всего. Также они некликабельны. Ну вот здесь просто, ну, на мой взгляд, гораздо симпатичнее. Так. Угу. Ну вот тоже здесь есть список покупок. Ну как бы вот вы сами видите. В Lavable получился гораздо более качественный дизайн. Давайте мы попробуем опубликовать его. Открываем. Ну вот она так симпатично выглядит. Можно поменять тему. Что мы ещё можем сделать? Давайте вернёмся на интерфейс Lavable. И мы можем здесь перейти на вкладку код. Вот, если её здесь не будет, то можно через плюсик добавить. Мы переходим в код и видим и видим весь код нашего приложения. Мы можем вот отсюда вот скачать весь вот этот проект и открыть его потом в курсоре и уже в курсоре потом что-то править, какие-то делать правки по коду.

Теперь мы давайте вернёмся в курсор. Итого, вот у нас есть вот эта штука, созданная в курсоре. Потом есть вот эта штука по одному и тому же промту, созданная в Lavable. И теперь давайте мы откроем другой проект и попробуем сделать другой пром, более такой расширенный в курсоре. Попробуем подключить кое-какие хаки, кое-какие MCP и посмотрим, что у нас сделает курсор именно уже по другому промту, по более расширенному. Давайте я закрою курсор, открою его по новой. Open Project. Давайте мы перейдём на вкладочку Cursor Project. И здесь мы создадим новую папочку. Назовём её Super SAS VPП. И теперь смотрите, что мы здесь сделаем.

Первым делом мы подключим MCP SHATCN. Что такое SHATCN? Давайте я открою шаcn. Вот это такой сайт, где мы можем видеть различные компоненты. кнопки, инпуты, всякие аккордеоны, чекбоксы, всякие готовые формы. Это, в общем, такая библиотека, которую используют все-все фронтендеры для того, чтобы сделать дизайн более таким современным, динамичным и так далее. И в целом, если курсору написать, что использую ШтCN библиотеку, он будет её использовать, но это будет немножечко, так сказать, сыро, костыльно. Он будет пробовать пересоздавать какие-то компоненты и так далее. Поэтому курсору нужно как-то задать, чтобы он прямо к этой библиотеке обращался как к внешнему источнику. И мы это сделаем. То есть мы, если сейчас ведём в браузере SHCN MCP, то мы вот переходим на этот же сайт Шсина. И здесь он нам для курсора говорит, как нужно поставить MCP шат. Вот мы вводим эту команду в терминале, нажимаете Enter. Если у вас шат MCP не поставлен, то он установится. И после этого мы возвращаемся обратно в курсор, возвращаемся в настройки, переходим в Tools MCP. И мы видим, что у нас установлено шат CN, шат CN MCP. Вот давайте вот это MCP оставим.

И теперь помимо этого давайте мы ещё откроем сайт curсоor.dory и здесь возьмём какой-нибудь rules extension typescript React frontend. Ну давайте вот этот. Давайте возьмём реально вот этот. Скопируем. Открываем. Переходим в rulesсы и добавляем кастомный rule и назовём её senor front and rule. Назвали, скопировали, сохранили и all supply. То есть, что оно это правило применяется всегда. Всё, мы это сделали. Итого мы добавили такой кастомный промт, который нам будет писать как профессиональный фронтENД-разработчик, и добавили шатcn, к которому будем обращаться, чтобы сделать наше веб-приложение такое более динамичное и обогащённое современными компонентами.

Теперь я подготовил заранее промт. Я его сейчас писать не буду, но видите, он гораздогораздо более детально проработанный. То есть здесь главное, что мы указываем дизайн-систему строго. Что вообще такое дизайнсистемы? Дизайнсистема - это, по сути, такой набор правил и готовых кирпичиков, по которым собирается интерфейс продукта. Внутри дизайнсистемы обычно есть сетка и отступы, типа графика, цвета состояния, компоненты, то есть это различные кнопки, карточки, формы, табы, разные правила, как их задавать. Что даёт дизайнсистема? Дизайнсистема даёт прежде всего единый стиль на всех страницах. Ничего не пляшет. скорость разработки, опять же, потому что ты берёшь готовые компоненты и собираешь UI как конструктор. Меньше багов и переделок, так как одинаковые состояния и поведение системы везде одинаково. Проще масштабировать, так как добавляешь новые экраны, и дизайн остаётся цельным всегда. Проще говоря, без дизайн-системы сайт часто выглядит случайным, а с дизайн-системой как настоящий такой продукт, сделанный профессиональным дизайнером. Что тут у нас ещё есть? У нас здесь есть рецепты, список покупок, статистика, в общем, UX требования. В общем, всё я подробно расписал, что я хочу увидеть. Итого, смотрите, мы

сейчас вот это вот добавим. Добавим. И смотрите, дополнительно мы напишем: "Используй mcp shot cn". И давайте ещё добавим. Он, в принципе, должен взять, но давайте добавим в контекст вот это наше правило senior frontend rule. Всё, в целом, в целом всё. Погнали.

Нажимаем Enter. И теперь я подозреваю, что мы будем очень долго ждать, что же нам курсор такое сделает. Инициировать React проект. Создать страницу. Так, раскрываем папочку Mail Mind. Видим все наши компоненты. И теперь давайте попросим курсора запустить наше приложение. Теперь давай запустим приложение и откроем вот по этому адресу. Так. И у нас, смотрите, выходит ошибка. Давайте прямо мы её курсору скинем. Вижу ошибку. Исправь. Так, по адресу вот этому. Так, мы, кажется, исправили все ошибки. Давайте, кстати, нажмём Пол. И теперь давайте попробуем открыть по нашему адресу, вот по этому Open. Open in External Browser. Оно открывается в Хроме. И смотрите, ну, в целом, да, видите, то есть оно выглядит гораздо симпатичнее по такому вот расширенному промту с дизайн-системой. Вот переключимся на тёмную тему. Да, давайте сравним. То есть вот это получается приложение, которое курсор сделал по простому такому промту, без всяких MCP и так далее. Вот это получается он сделал по расширенному промту с MCP, но видите, гораздо-гораздо симпатичнее. А вот это приложение нам сделало Lavable. Ну, смотрите, на самом деле тут на любителя, да, возможно, Lava был чуть-чуть посимпатичнее за счёт вот этих иконок, которые Lavable подтянула. Здесь нет никаких иконок, ну, допустим, вот здесь, да, список покупок могли бы быть какие-то возможные иконки. Вот видите, здесь они есть. Такой чек-лист более приятный. Ну да, наверное, в Lavable Sй получился более такой симпатичный, чем в курсоре, но в целом можно и в Lavable тоже скармливать подробный промт с дизайн-системой, потом код уже копировать, скачивать и открывать его в курсоре и доделывать.

А теперь мы с вами поговорим, как же нужно верстать при помощи курсора. Я создал вот такой вот пустой проект, назвал его кописайт. И здесь у меня из правил моё системное правило обычное, дальше правило проектное о том, что я front-end девелопер и так далее. Ну, кстати, по-моему, даже оно не применилось, да? Давайте откроем сайт. Вот gets курсор. Скопировать. Ставим вот это правило. Always apply. Всё, сохраним, откроем. Да, теперь оно применилось. В общем, у нас правило о том, что мы там frontend девелопер, круто верстаем, круто всё делаем. Системное правило. И дальше у меня из MCP также стоит SHCN, ну и все разные другие MCP. Так. А дальше мы возвращаемся на вкладку Agent. Закрываем. Так, Editor. Вот. У нас дитор, вкладка Agent. И смотрите, дальше мы открываем Фигму. В Фигме я нашёл вот такой вот макет, такой вот сайт. Фигма - это инструмент, которым пользуются все дизайнеры. Они там проектируют дизайн. И после этого по этому дизайну разработчики верстают сайт, то есть делают так, чтобы он работал в коде. И смотрите, мы здесь не будем верстать весь проект. Я нашёл вот дизайн вот такого вот сайта. Мы здесь вот откроем вот эту вот страницу. И здесь можно посмотреть вот каждый компонент, что он из себя представляет. Можно вот навести вот этот вот хедер, посмотреть, что здесь есть, посмотреть, какие у него отступы и так далее. И здесь у нас прописаны различные отступы, пейдинги и так далее. И вот мы здесь можем вот нажать контекстное меню Фигме и сказать copy Sopд и выделить прямо все CS этого элемента и скинуть курсору, чтобы он нам сделал по аналогии, сверстал по аналогии. Здесь, на самом деле, можно вот нажать сюда make code from design, но мы сейчас это не будем делать. На самом деле в Фигме тоже есть очень много различных возможностей. Также есть Figma Make, где можно прямо заниматься так называемым вайб-дизайном. То есть можно прямо задизайнить проект, который вы хотите. Вот. Но сейчас мы это не рассматриваем. Возможно, в следующих видео я это обязательно рассмотрю. Ну, в общем, смотрите, какая у нас цель. Давайте мы прямо сделаем скриншот вот этого элемента. Вот так вот. Сделаем скриншот. Ставим в курсор. Ставим в курсор. И смотрите, я заранее подготовил промптt. Сейчас я, чтобы его не писать, сейчас я его скопирую, и мы его немножечко разберём. Давайте мы вот сюда его вставим. Задача сверстать 1.1. Максимальный пиксель приближённо секции по принк сшоту из Фигма. Данные у нас скриншот макета, который мы сейчас предоставили, и CSS Allers и Figma ниже. И давайте, смотрите, мы ниже вот после этого, ну, то есть смотрите, я пишу технологии, я пишу структуру, что вот у нас есть, есть, есть, есть визуальный блок, есть какие-то заголовки, то всё подробно приписываю. Промты я обязательно приложу в описании к видео. И после этого я вставляю CSS allers. И давайте мы прям выделим все вот эти вот лайры. Давайте вот так. Скопируем вот этот вот блок копиssсли. И вот здесь приложим вот эти стили. Потом чем отличается копия CSS от копи CSS All LERS? Ну, я так понимаю, здесь он нам именно копирует все стили, в том числе и вложенные. Поэтому я делаю вот именно вот это. Ага. То есть вот шапка, вот этот блок. И давайте теперь, а вот этот блок у нас есть копия AS. Ну, и, пожалуй, всё. Давайте теперь я скопирую полностью вот этот вот блок, вернусь, курсор. Вот так его вставлю. Всё, погнали. И вставим Enter. И посмотрим, что нам сделает курсор. Курсор нам пишет, что он закончил, готово. Создал компонент с точными значениями, ключевые значения и так далее. Так, ну давайте нажмём keep. И смотрите, курсор на самом деле всё закончил, но тут он немножечко подвис. Видите, тут даже какие-то у него глюки, вёрстка поехала. Но тем не менее я открыл в локальном браузере курсоровском. Вот так вот выглядит сайт. Давайте я открою его здесь вот вот этот сайт Фигми, как он выглядит, да, как дизайнер нарисовал и как мы должны были его сверстать. И вот так он выглядит на сайте. По-моему, супер. Ну, очень даже похоже. Фактически один в один. Ну да. Видите, здесь вот стрелочка такая, а здесь вот у нас стрелочка, ну, такая, да, кривая. Можно сказать, что нет стрелочки. Вот это надо поправить. Плюс картинка. Ну, видите, здесь такая, а здесь как бы, ну, надо было просто вот эту картинку здесь экспортировать во Фигме и прямо положить в проект в курсоре. Тогда он, конечно же, сделал бы точно такую же картинку. А так, видите, в целом вот менюшка, да, всё, шрифты и так далее, всё в целом так же, как и в макете. И вот так вот по аналогии и верстаются все сайты. То есть точно так же потом мы бы сверстали остальные все пункты, вот эти, вот эти, под мобильную версию. На самом деле это делается даже ещё немножко попроще. Есть Фигма MCP, мы точно также можем подключиться к Фигме. Точно также всё верстать через Фигму. У нас курсор будет через Сигму видеть все отступы и так далее. Но практика моя показывает, что помимо подключения ФигM MCP лучше всё равно вот таким образом, как я это делал в курсоре, делал скриншот и скидывал его курсору. То есть всё равно так тоже лучше делать дополнительно с фиг MCP. Так он будет верстать ещё лучше прямо в точности по макету.

Теперь давайте уйдём немного в сторону от курсора к чат GPT и немного поговорим о ручном тестировании и попробуем облегчить жизнь тестировщикам, которые не пишут автотесты, а именно занимаются manual QA. И начнём мы с того, что я подготовил два промта, один для чек-листов, другой для тесткейсов. Моя позиция такая, что в начале, когда тестировщик только, допустим, тестирует функционал или даже только не тестирует, а ознакомится с требованиями, хорошая практика. Считается, что тестровщик сразу на эти требования пишет тест-кейсы. Но на моём опыте и на опыте моих коллег, как правило, очень редко это получается. И правильный подход то, что тестировщик на требования вначале пишет чек-листы, а уже после того, как он эти чек-листы написал, уже после того, как их отревьют системный аналитик, его коллеги, тестровщики, продукт-менеджеры, возможно, после этого эти чек-листы уже можно написать в более детализированные тест-кейсы, либо после того, как уже функционал готов, подправить чек-листы и на основе этих чек-листов написать тесткейсы И примерно то же самое мы и будем делать. Я подготовил вот такие два промта для чеклиста и для тесткейса. Как я уже говорил, все промты будут в описании к видео. Давайте разберём промт для чек-листа. Ты сеньор QA инженер с огромной экспертизой в тест-дизайне и тест-анализе. Сгенерируй полный структурированный чек-лист для тестирования такого-то функционала на основе требований скрин, API, ограничений. В общем, всё, что всё, что у вас есть, любая документация. И общие правила: полнота позитивная, негативная, пограничные значения, валидация, ошибки, интерфейс, безопасность, производительность, крусбраность, адаптивность, если актуально. Дальше томарность, один пункт, одна проверка. Ясность, формулирую коротко, без сложных условий, терминов независимость. Каждый пункт можно выполнить отдельно. Структура, группируй проверки по логическим разделам или экранам. Универсальность чек-лист должен быть понятен даже для Junior QA. Переносимость формация вместе SOPS Google Sheits. Вы можете, конечно, что-то своё добавить, но это вот такой вот промпт универсальный я составил. Явно указываю условия тестирования, браузер, устройство роль локаль. Дальше я указал области покрытия, основной функционал, крат, бизнес-логика, негативный сценарий, ошибки, невалидные действия, валидация данных, обязательные поля, форматы, ограничения, поведения интерфейса, элементы перехода, сообщения, сообщение, сообщения об ошибках и, в общем, так далее. Я это расписал. Расписал шаблон оформления, да, то есть с маркдауном, условия, описание, а, описал примеры, раздел, название раздела, например, регистрация и такой-то пункт, такой-то пункт, такой-то пункт, такая-то проверка. Дальше название следующего раздела, например, авторизация и так далее. Дальше указал вывод. Сначала краткий чек-лист покрытий по областям из области покрытия, затем развёрнутый чек-лист в формате шаблона по разделам, не добавляя пояснения, комментариев или рассуждений. И опять же указал входные артефакты, то, что мы можем дать требования, если требований нет, скрин, либо какую-то опишку, либо как-то что-то словами написать. И подобное, на самом деле, я написал для тесткейса. Даже у меня получилось короче. Здесь то же самое. Ты сниженер с огромной экспертизой в тест-дизайне и тест-анализ сгенерирует полный набору тест кейсов для такого-то функционала. И общие правила: полнота, позитивная, негативная, пограниченная, валидация с общением ошибка, доступность, безопасность, кросбраузерность, платформы, если актуальна, атомарность, однозначность. И указал вот такой вот шаблончик тесткейса стандартный, где будет айдишка его, названия, связанные требования, предусловия, шаги, ожидаемый результат, приоритет, либо highй, либо medмедиум, либо low и разные примечания. Браузер, устройство, роли, данные. И вывод сначала краткий чек-лист секциями список покрытий, затем полный набор из кейсов по шаблону. Каждый кейс отдельно без нумерованных вложений. И также входные артефакты. Вот такие вот промты я подготовил.

И теперь давайте попробуем их применить. Что мы будем сейчас тестировать? На что мы будем писать чек-листы, потом тесткейсы? Мой прошлый работодатель, в котором я уже, наверное, года полтора, а может и два не работаю, это компания Жива. Она известна как живой сайт, живой, живочат для англоязычной аудитории, живо для бразильской аудитории. Ну, в принципе, для русскоязычной. А наверняка вы о нём слышали. В СНГ он номер один, в Турции он номер один, в Бразилии он номер один, где-то он номер два. Ну, в общем, это такой онлайн-консультант плюс CRM в одном лице. Вы наверняка любой сайт, когда открывали, у вас появляется какой-то чат на сайте. Это есть скорее всего живо. И точно также этот чат можно строить не только на сайты, можно и встроить в какие-то мобильные приложения. И давайте мы, я подготовил, Android Studia, поставил вот этот сайт живо. Сейчас мы здесь авторизуемся, и мы попадаем на главный экран Inbox, my all, так называемое вот мобильное приложение Живо, админка. И мы можем поставить какой-то онлайн-консультант на сайте. С этого онлайн-консультанта кто-то напишет. Ну, давайте, не знаю, к примеру, можно открыть какой-то сайт.ru, и здесь будет внизу онлайн-консультант высветится. Вот он, видите? Напишите нам. И вот мы здесь пишем. И после того, как мы это сделали, к нам в приложение вот сюда придёт сообщение от клиента. Мы его можем как-то сгруппировать, что-то сделать, поставить какую-то сделку на него, напоминание. А, и так далее. Вот такое вот мобильное приложение. Представим, что нет никакой документации. В целом в компании не было каких-то системных аналитиков, да, даже бизнес-аналитиков не было. Но зато я знаю, что очень есть хорошая на сайте живочат пользовательская документация. Её писала наша техподдержка. Не знаю, кто сейчас пишет, наверное, они же. И, в общем, она была довольно-таки неплохая. Представим, что это всё, что у нас есть. И теперь давайте откроем браузер, откроем чат GPT и вот здесь создадим отдельную папочку, назовём её тестирование Gва. И здесь будем писать все наши запросы, прикладывать какую-то информацию. В целом я также рекомендую вам делать с любой нейросетью, которой вы работаете. Неважно, это какой-нибудь Qн или Perpкти, везде можно создать папочку, проект. Здесь будет запоминаться контекст, вся информация по этому проекту, и вы можете здесь прямо писать запросы и работать. И смотрите, давайте теперь сделаем так. Android Studio откроем, сделаем скриншот. Вот сделали скриншот. Приложим его чат GPT. Приложили. И теперь пишем это основной рабочий экран диалоги нашего приложения. Напишем, что это мобильное приложение живо под Android. И прямо так и напишем. Прежде чем писать чек-листы. Найди мне всю документацию для живо, которая есть в интернете. И только после этого на основе информации напиши мне чек-листы. Давайте в скобочках укажем только основные для мобильного приложения на основе вот этой инструкции. Давайте откроем сразу нашу инструкцию для чек-листа, для тестирования. Давайте укажем живо. мобильного мобильного живо под Android на основе скриншота. И здесь входные артефакты. Давайте укажем скрин скриншот. Всё. Теперь вот это вот скопируем, откроем браузер и прямо вот так вот вставляем. И теперь давайте посмотрим, какие он нам чек-листы напишет. Мы видим, он ищет по всему интернету документацию. Видите, перечисляет сайты. Сейчас, скорее всего, дойдёт до главного сайта. Это.ru либо.com. Ну, в общем, какой-то такой. И, видимо, оттуда распарсят информацию и на основе её попробовать нам написать чек-листы. А мы посмотрим, какого они качества. Так, ну, мы видим, какой-то результат он нам уже выдаёт. Давайте сразу читать. Так как я с этим приложением знаком, в целом, я, наверное, смогу оценить, корректны ли чек-листы или нет. Итак, основной функционал. Загрузка рабочего экрана. Ага. Отображение списка диалогов во вкладке Inbox. Отображение диалогов, назначенных на операторов во вкладке My. Отображение всех диалогов. Запуск с тестового чата по кнопке send message to self. Ага. Да. То есть действительно здесь можно отправить самому себе чат. Давайте вернёмся. Переход на вкладки Task Visitor Team. Ага. Пустой список диалогов. Экран без чатов. Да. Ошибка загрузки диалогов. Нет, CT сервер недоступен. Действительно, да, есть такой кейс, что когда интернета нет, то у нас там должен быть определённый определённый баннер, некорректный ответ от сервера по списку диалогов, недоступность отдельных вкладок по правам. Да, действительно, у нас а было так, что всё зависит от роли. Если какая-то роль, то ты там что-то мог не видеть. Корректный поиск по диалогам, по тексту имени клиента, каналу. Действительно, да, так можно искать. Обработка пустого поискового запроса. Правильное состояние вкладак. Состояние переключения. Да. Да. Ну, кстати, довольно неплохие чек-листы. Обработка тапов поиску звонку ниже меню. Корректное отображение пустого состояния. Да, действительно. Ага. Сообщение при отсутствии сети. Сообщения при тайм-ауте сервера. Привозможности открыть доступ только после авторизации. Да. А блокировка. Производительность. Ага. Особые условия. Поведение. Ага. Введение приключений. Работа с разными локалями. В условия тестирования. Загрузка отображения рабочего экрана. Не при повторном запуске. Вкладки Inbox. Ага. Фокус не изменяет подсветку. Переключение вкладок. Список диалогов. Устой состояние. Inbox. Угу. После возврата счатанный экран, новый диалог отображается корректно. Да. Всё так. Всё так. Ну, кстати, реально прям неплохие чек-листы. Автоматически фокусируется после ввода. Нижняя навигация. Навигация. Чтон? Валидность данных. Локализация, безопасность. Производительность. Вот. При входящем звонке на телефон, время работы контакзо приложение корректно уходит в фон и возвращается без потери соединения. То есть такие уже чисто хитрые мобильные чек-листы. При смене сети список диалогов восстанавливается без необходимости принудительного перезапуска. При низком уровне батареи экранконтакт-центр продолжает корректно работать. Ну реально интересно. Интересно, да.

И давайте теперь попробуем на какой-нибудь разделщик листами написать тесткейсы. Вот давайте на раздел пять. А теперь на раздел пять напиши мне тесткейсы согласно следующей инструкции. И давайте теперь откроем инструкцию по тесткейсам мобильного. Тут можно описать функционал, что это верхняя панель, но в целом давайте просто общее напишем для мобильного приложения живо под Android. Здесь, соответственно, всё так же. И здесь скриншот. В принципе, можно не писать, так как он на основе чеклиста будет писать тесткейс. И теперь давайте сюда вставляем. Так, вот уберём вот это лишнее. Скопировали. Ну и всё, погнали. Пишет перед тесткейсом краткий чек-лист покрытий, аватар. Вот и выполнение поведение. И дальше уже пишет тесткейсы. Открытие профиля после по тапу на аватар. Позле авторизован под ролью agent. То есть понимает, да, что есть разные роли. Открыт контакт-центр с видимой верхней панелью. Тапнуть по аватару пользователя на верхней панели. Ждаемый результат. Открывается экран профиль настроек с данными текущего аккаунта. Ага, даже написал. Вот где следует смотреть. Изображение кредит названия в аккаунте, в заголовке. Приверите текст заголовка рядом с аватаром. Угу. Точно название аккаунта. А, без обрезки и артефактов. Угу. Открыт экран. Отображается поле поиска по диалогам. А курсор установлен в поле открытая клавиатура. Угу. Поиск по диалогам, по существующему тексту. Есть минимум два диалога. Один из них содержит уникальное слово. Тест живо. Открыт экран. Угу. Да. Тапнуть по иконке поиск. Ввести в поле. Подтвердить поиск. Либо один диалог с этим словом. Угу. Один. Да. Да. То же самое, да, должно работать box all. Ну я всё не буду просматривать, но в общем принцип вы поняли. то а теперь мы перейдём к самому интересному.

И мы откроем наш проект, который мы будем автотестить. Это реальный проект личного кабинета поставщика. Суть личного кабинета поставщика в том, что там регистрируются различные поставщики и заводят различные товары, карточки товаров, заполняют кучу каких-то форм. И на этот личный кабинет есть опишка, которая задокументирована в славагере. Вот такой вот свагер. В свагере есть различные методы: аналитика, профиль, промо, включение и так далее. Куча всяких методов. И можно открыть раздел аналитики. И здесь мы видим куча ручек по аналитике. Можем открыть раздел профиль и будем видеть кучу ручек по профилю. И можем открыть раздел промо и будем видеть кучу ручек по промы. Итак, теперь я открою в другой диешке, так как мне удобнее работать с ней. Прямо код пишу я в этой водиешке в интеjectкде, а кожу я в курсоре. И мы откроем вот сейчас личный кабинет поставщика. Мы откроем наши опишные тесты. Лежат они здесь. И мы открыли файл промотест. И смотрите, давайте мы вначале откроем Свагер. Давайте попробуем теперь вот с промо акций, вот с этого раздела, вот на эти методы с с документацией свагеровской нагенерить тесткейсов, а потом с этих тесткейсов нагенерить автотесты. Вот план такой. Смотрите, представьте ситуацию. У нас нет никаких тесткейсов, нет времени тут срочек вписать эти тесткейсы. Есть только документация на слагерь, и мы считаем, что она актуальная. Больше ничего нет. По сути, такая ситуация есть на этом проекте. На этом проекте, ну, не так много тестровщиков. Здесь выпускается огромное количество фичей. Свагер более-менее актуальный. Команде нужно как-то выживать, нужно как-то покрывать регресс, хотя бы опишный. В этой команде напилены автотесты. Я напилил определённое количество автотестов. И смотрите, и давайте мы немножечко сейчас разберём один автотест, на основе которого мы будем это всё генерировать. Автотест здесь написаны на стшоге и на Gunit пятом. И смотрите, здесь я не буду объяснять какие-то уже нюансы, да, сейчас моё объяснение уже будет больше не для новичков, а для тех, кто уже имеет дело с автотестами. Здесь поставлены какие-то теги и какие-то аннотации. G пятовский, на которой написаны экстеншены, но не суть. В общем, вот у нас есть тест. И смотрите, как он выглядит. Мы вызываем либо make, либо get, либо post. Дальше мы передаём одним из параметров в этом метод спецификацию. Я в дальнейшем расскажу, что это. Но в спецификации мы указываем токен, под которым хотим произвести тест. мы указываем какие-то заголовки, какой-то базовый URL. В общем, всю такую базовую информацию мы указываем здесь. Дальше мы указываем endpoint promo. В данном случае у нас здесь будет зашит базовый ORL. И сюда прибавляется endpint промо, к которому мы хотим обратиться. Дальше мы через map of передаём какие-то параметры, которые мы хотим вызвать. После этого, после того, как мы это сделали, и дальше в боде мы тут же в этой же цепочке мы проверяем, что статус равен success, что у нас возвращается Jon и у него bodyфilльтр name равен блинчики. Body filter name by declaration равно тоже блинчики и фильтр technologies равно такой-то. Вот. И мы хотим, чтобы все тесты были такие. Да, я понимаю, что они не идеальные. К примеру, вот это всё можно было бы проверять более изящно, да, через мягкие проверки, черезы. Также вот это всё и вот это всё можно было бы запихать в модели, в позже классы. Ну, в общем, мы считаем, что вот текущая архитектура, текущая структура автотестов, она тестировщиков устраивает. Они не хотят ничего менять, и они хотят, чтобы все тесты писались так, чтобы именно они писали через makeet, make post, make pass и так далее, через все мейки. Никаких других обёрток им не нужно дополнительных, никаких других абстракций им не нужно. И дальше мы бы указывали какую-то спецификацию, под которой мы авторизуемся там с нужными заголовками и так далее. Вот. И передавали вот так вот параметры через mapпов и в боде всё проверяли. Всё. Мы считаем, что вот такие автотесты понимают любые QA, даже которые не разбираются в коде, им лень это делать, и они могут писать такие тесты. Вот. Давайте мы попробуем запустить. Запускаем. Я надеюсь, у нас тест пройдёт. И всё, тест проходит. И смотрите, этот тест, если мы вернёмся сюда, он у нас вот он, да, вот на на эту ручку.

Что мы дальше делаем? Нам вот этот сваiger необходимо скачать и положить в наш проект с автотестами. Вот скачать мы его можем вот так вот. Apog email. Мы его просто скачиваем. А где-то там это может быть жека и можно будет скачать жекой. Где-то будет емуэлька. При этом этаэлька, вот давайте её здесь откроем. Вот она, видите, она ссылается ссылками на другие мэльки. Вот это нам не подходит. Нам нужно поговорить с разработчиками как раз, которые ведут вот этот проект и поговорить, как они у себя хранят свагер. Они нам объясняют, как они хранят свагер. И сwager, на самом деле проектируется по-разному. Где-то это может быть, где-то это может быть Jon. При этом Jon этот может быть единый, а может быть единый, а может быть не единый. А он ссылается у себя внутри на другие имейли одним файлом, тогда его скачать не получится. Тут нужно поговорить с разработчиками и спросить, в каком виде в проекте у них лежит свагер. Я это сделал, я с ними поговорил. И что я сделал? Я в итоге в проект с автотестами закинул полностью слагер. Давайте я покажу, как я это сделал. Я взял папочку с ихнего проекта, с бэкэндо у разработчиков. Она называется папочка IPGS, и скопировал её полностью из ихнего проекта к себе. Вот она. И если здесь я открою IPOC email, у меня за счёт плагина в Intelctде загрузится как раз вот ихний Свагер. И то есть сейчас Swager у меня живёт в моём проекте с автотестами. И получается, что курсор у меня сможет проанализировать весь мой проект с автотестами, взять мой слагер прямо с исходного кода и на основе слагера нагерить тесткейсы и нагенерить автотесты. Теперь давайте попробуем это сделать. Итого, мы сейчас поняли, какая нам нужна структура. Смотрите, мы понимаем, что вот этот вот тест для нас, он будет пока что идеальный. Мы хотим, чтобы курсор вот в таком виде генерил все автотесты. И вот я объяснил вам примерно всю структуру. И дальше у нас есть свар прямо в проекте. А теперь мы откроем курсор и уже наш проект с автотестами. Давайте переключимся так через плагин. Вот. И откроем папочку LKVUI test. Откроем LKVU тест. Теперь мы переключимся настройки руса. И у нас здесь нет никаких русов. И мы добавим первое правило - это user rules, про который я вам рассказывал. Я вот его уже подготовил. Не буду его по новой составлять. Я вот просто его вот здесь вставлю и сохраню. Вот я это сделал. Ну, здесь можно добавить несколько пользовательских правил, но мне достаточно одного. Давайте мы его немножко разберём. В целом это правило такое довольно выстраданное. Я вначале использовал одно правило, потом использовал другое, много с ними ковырялся, ни один проект с ними не создал. И потом в

В итоге комбинации нескольких правил. Одно я посмотрел у одного блогера, второй посмотрел у другого, что-то ставил под себя. И у меня в итоге родилось вот такое вот правило. Оно в целом простое. Оно говорит о том, что как бы делай всё хорошо, не делай всё плохо, пиши как можно проще. После того, как написал, подумай, перепроверь, ещё раз, перепиши по-нормальному, а, и так далее. И перед каждым ответом обязательно читай правила.

Вот, на самом деле, вот эти правила, которые мы сейчас зададим в пользовательских правилах в User Rules, они автоматом читаются курсором, да? И он нам говорит, что автоматом читай правила из проекта Cursor Rules. Что это значит? Вот когда мы создадим вот здесь правила проектные, они автоматом создадутся в папочке Cursor Rules. И курсор он вначале читает позительские правила, твоё личное, а потом читает уже проектные правила, которые, соответственно, я запушу и которые в итоге получат все тестировщики.

Мы можем, на самом деле, передать это проектное правило вот здесь через контекстное меню, да, и передать это проектное правило, которое у нас будет. Но на самом деле не всегда это хочется делать, передавать, иногда это забываешь. И несмотря на то, что курсор должен по сути вот эти проектные правила всегда читать, но он не всегда это делает. И поэтому в системном правиле, в пользем я дополнительно пишу, что перед каждым ответом обязательно читай правила. Не приступай к ответу, пока-нибудь прочтёшь правила.

Каждый свой ответ без исключения, начиная с фразы "в контекст". Вот это называется контекст, да, когда мы какую-то папку добавляем, вот какой-то файл, чтобы курсор он проанализировал вот именно вот эти файлы, которые мы ему передаём. На самом деле, курсор сейчас анализирует весь проект, но всё равно, когда мы передаём какие-то файлы, он как бы более тщательно их анализирует, скажем так. И видите, это такой хак хитрый, чтобы курсор железный всегда вот эти правила читал. Курсор он всегда будет свой ответ без исключения начинать с фразы "в контекст добавлены правила". И раз он как бы это будет начинать, он меня будет обманывать, он будет всегда в контекст эти правила добавлять. Всё, мы добавили правило. Вот оно. Ещё раз сохраним.

Видите, я позлю Mac и написал "I'm using Mac". Вы можете написать "I'm using Window". И у меня где-то здесь на русском, где-то на английском. Раньше считалось, что курсор работает с промтами, различными справами, которые а написаны на английском языке. Ну, на самом деле, сейчас это не так. Сейчас можно писать и на только на русском, и только на английском, и на русском, и на английском, и смешивать, как я это делаю. И в целом разницы никакой я не вижу.

Дальше теперь мы добавим следующее правило. Мы будем работать, смотрите, а курсор, как и вообще другиешки, как и в целом люди, они работают хорошо с короткими задачами. И как и для людей, так и дляшек нужно декомпозировать задачу на шаги. И курсор очень хорошо вот с декомпозированными задачами работает. Плюс есть такая фишка, что очень хорошо ввести некий roadmap и говорить курсору, чтобы он в roadmap внёс, что он делает, внёс, что он закончил, внёс какие-то новые задачи. И вот я составил такое вот правило. Давайте я его здесь применю. Мы нажимаем Project Rules. И давайте назовём вот RODMAP. Так вот, давайте Project Truls и назовём R map Rule. И вот так вот скопируем и его укажем.

Давайте здесь мы в доках создадим сейчас папочку, назовём её Docs. Docs. И потом в папочке мы создадим файл и назовём файл road map. Вот создали. Вернёмся в наше правила. Ещё раз возвращаемся вз. Так. И вот смотрите, теперь мы, если перейдём вот по этой ссылке, мы попадаем в наш MD, в которой он будет описать. Что здесь написано? Всегда следует плану описанный Wordmap. У нас Wordmap будет план, который мы попозже наерим. Перед тем, как начать формировать ответ, определи на каком шагема ты сейчас находишься. Если запрос пользователя противоречит плану, всё равно выполни его, но зафиксируй это в РДмапе. Если запрос не связан с текущим проектом, также выполни его, не нарушая основной структуры. После завершения каждой задачи обнови файл, отмечая выполненные шаги. Если пользователь выполняет шаги в другом порядке, всё равно отмечай их как выполненные в Redmap. В конце каждого ответа сообщай пользователю, какие шаги выполнены в формате названия шага. использую формуровки шагов из Wordmap. Реализую только те пы, которые она указаны вmap. И указал ему примеры.

Что будет делать курсор? Курсор, как только будет что-то выполнять в рдмапе, он будет помечать, что шаг выполнен. И дополнительно я указываю, чтобы Ишка мне писал, что roadmap обновлён, когда он действительно обновляется, когда действительно в Roadmap вводятся изменения. И того, что мы имеем, так сохраним. И теперь, видите, у нас появилось правило, и мы можем указать, что всегда применяй это правило каким-то специфичными файлами и только если мы будем ссылаться на это правило. Давайте мы сделаем always apply. Всегда применяй это правило. Так, сделали.

Теперь давайте мы откроем браузер и курсор Directory. Вот это такой популярный сайт, где мы можем посмотреть кучу различных правил. трендинг MCP, про которую мы чуть позже поговорим для курсора. Давайте теперь возьмём здесь и найдём какое-нибудь правило, которое будет посвящено тестированию. Вот у нас несколько правил посвящённо тестированию. Тут, в общем, нет правил по Java, но есть вот это вот правило. Оно Automation, Engнир Expert, Typescript, JavaScript, frontend developer и так далее. Смотрите, я беру его, копирую и прямо в курсоре вставляю его вот в новое окно. agent. Выбираю здесь и давайте вот вот у нас окно агента. И вот вставляю, вычитаю примерно. Сейчас я не буду особо это делать, но вы должны его прочитать. И теперь я пишу, я понимаю, что мы используем G unit п gradл. У нас уже есть веб-автотесты в этом проекте. Мы используем SNIT, а здесь всё это вообще, ну, как бы для тайпскрипта и для джаваскрипта. Но в целом нам это правило, допустим, нравится. Мы его почитали, и мы пишем: "Проанализируй". Проанализируй текущий проект и перепиши это правило под то, что ты senor senior coomizationomization expert in Java Java. И ты используешь и ты используешь следующие технологии: G Unit 5, Gradle, Selenit, Rest Shit и Page Object. И перепиши это правило под текущий проект и под то, что ты синерку автонер эксперт, ты используеш следущий градус limitш page object. Вот. И давайте постраим дето. И смотрите, я вот здесь немножко тоже прочитал и понял, что здесь нет ничего про тесткейсы, про там техники тест дизайна. И давайте ещё вот так вот тогда напишем. Плюс добавь, что ты эксперт по техникам тест дизайна, дизайна и написанию скейсов. Такой синьор QA инженер и написание тесткейсов. Всё, давайте попробуем теперь в режиме Askсим. Вот. И теперь немножко подождём. И вот таким образом вы можете писать сами промты. Ничего в этом сложного нет. писать промты, писать правила и так далее. Кстати, давайте даже остановим и в режиме агента попросим это сделать. Вот в режиме агента ещё раз, чтобы он сразу это правило написал. Вот здесь, видите, у нас показывается прогресс контекста. Что такое контекст? Это курсор запоминает всё то, что мы писали в рамках одной сессии. И как только контекст заканчивается, то курсор уже не запоминает всю предыдущую информацию с прошлого чата. И нужно как бы писать по новой. Поэтому следите вот за этой штукой. Не делайте слишком каких-то больших команд, чтобы у вас быстро заканчивался контекст. И видите, он нам пишет сейчас как раз различные правила. Вернёмся в режим агента. Вот и посмотрим, что он написал. И expert в Java Gunit Gradit, техника тест дизайна. Окей, в принципе написания использу написаны смысленные тесты. Вот он, соответственно, взял, что у меня написано в проекте примерно и вот это тоже вот всё описал, что используй тотого для жине от пятого. Ага. Избегаю дублирование кода. При используй PG обдавай базовые классы. Окей. Селенит. Так, ну нас, в принципе, интересует именно по assured. Вот прошки тоже тут про сини больше указал. Best practice. Применяй для читаемости. Окей. Вот тут уже простошут body. Окей. О'кей. Итого теперь что мы имеем? Давайте провалимся в настройки и посмотрим. Теперь вот у нас вот здесь есть правила Coineer Guidelines и Redmap Rule. Теперь нам нужно ещё одно правило, и это правило будет документировать через Java Doc весь наш код, который мы будем писать. Давайте переключимся во вкладку агент. И прямо здесь в целом у нас контекста хватит. Напишем: "Напиши мне правило, которое будет писать документацию ко всем методам, которыю мы напишем через Java doc. Через Java doc. Нажимаем окей. Ждём". И видите, он нам уже пишет в контекст добавленные правила: RNAP rule, querer, Gulines и так далее. Работается самой системный проomt. И ждём, когда у нас сгенерится правила Java doc roll. Так, давайте посмотрим наше новое правило. Doкru apply. Ага. Всегда всегда я бы jaкуличным протектом helpклассы базовый extension структура. Ага. Параметры описание условий. Угу. Return и так далее. Да. Да. О'кей. Принимаем. Всё. нас в целом - это устра и воет.

Итак, что мы имеем на данный момент? Мы имеем первое правило по заполнению через Java Doc всех наших создаваемых методах в Java. Дальше мы имеем правило про то, что мы QA инженер Sеньenor, которое написано именно под наш проект. И с этим правилом у нас будут создаваться более качественные автотесты. Далее у нас есть правило, по которому мы заполняем Roadmap. И у нас есть системный промт, который я обязательно приложу к видео, который лично мне очень-очень помогает в работе.

Теперь давайте откроем наш тест. И мы понимаем, что у нас должны получиться аналогичные автотесты. нам должен сгенерить курсор. Я сейчас, чтобы не писать вот этот здоровый промт при вас, я его подготовил, и мы его немножечко разберём. Итак, что мы напишем курсору? Мы напишем, что тебе нужно покрыть автотестами методы в свагере на основе файлаdocs. Вот если мы IPOG.email открываем, у нас подгружается Swagger, и мы это и пишем, который лежит в папке IPOGS. Давай делать всё по шагам. Вот у нас папка IPGS. И вот здесь лежит файл IPOGS email. Первое, вначале тебе нужно на основе IPOX email сделать чек-листы в видепion в коде. Давайте сделаем чуть-чуть более правильно и напишем не desриption в коде, а сделать тесткейсы, сохранить их в файле test swager.m. Давайте так. Давай вначале сделаем это для одного раздела промоакции. Мы вначале будем делать это для одного раздела. Вот для этого, для самого короткого. Потестим этот раздел, посмотрим вообще на качество тесткейсов, на качество сгенерированных автотестов и потом продолжим с другими разделами.

Возвращаемся. После этого на основе этих тесткейсов напишем автотесты по следующим правилам. Для каждого такого раздела создавай отдельный класс. Вот у нас вот будет раздел промоакции, и для него будет создаваться отдельный класс с автотестами. Для написания автотестов строго используют только методы из APCORE request, make post request, make get request и так далее. Если какого-то метода не хватает, то создавая его в APCOR request по налоги make post request, make get request и так далее. То есть, что это значит? Давайте мы откроем нашкоore request. Вот у меня здесь есть make post make. И я хочу, чтобы иишка не создавало никакие дополнительные абстракции, кроме Make Post, MyGT, Make Pass и так далее. И всё. Я хочу, чтобы тесты были максимально простыми, без каких-то лишних абстракций. Просто, чтобы был один метод My get. Мы туда передаём, как я говорил, спецификацию, передаём endpint, на который мы делаем запрос. передаём сами данные и дальше в этой же цепочке в боде всё проверяем. Всё это всё, что я хочу.

Вернёмся в наш промт. Итого мы вот это написали. Дальше я пишу, что в тесте всегда используй specification LKV request specification user roll supplier botkin. Что это значит? Я понимаю, что вот во всех вот этих тестах вот этого раздела промакции я хочу авторизоваться под определённым технологом, под определённым поставщиком. И я знаю, что у меня вот этот поставщик должен быть вот этот. Поэтому я сразу вот это прописываю, чтобы у курсора не было возможности сделать шаг вправо, шаг влево и что-то мне испортить. В каждом тесте всегда проверяй, что бодистатус равен success. В каждом тесте проверяй, что любое одно возвращаемое значение не пустое. И в каждом тесте проверяй разные поля на основе схем из свагер, не дублируя одно и то же поле во всех тестах.

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

И теперь возвращаемся дальше. Всё, эти поля мы прописали. Все проверки должны быть прямо в тестовых методах. Не плоди лишних методов. Это значит, что вот все проверки, вот они должны быть здесь, и никаких дополнительных абстракций делать не нужно. Дальше в тегах каждому тесту проставлять только название и метода, к которому относится тест. Вот. Вот у нас вот такие вот есть теги, да? И я прошу его проставлять именно вот именно вот этот вот раздел промо акции. Так, дальше вот хороший пример автотеста, которые должны получиться. И дальше в целом я привожу вот этот же пример теста, который должен получиться. Но здесь я указываю, что вот bodyдистатус success и проверка фильтров body filter name not null value. Он не пустой. И здесь я рассказываю, почему он хороший. Я в этом тесте использую вот make request with query param. Вот я использую изqu. Я использую спецификацию вот эту вот. Вот здесь, да, я её использую. Я проверяю, что статус success. И я проверяю, что любое возвращаемое значение не ну. Вот как раз body filter name not null value. В данном случае проверяю body filter name. И дальше смотрите, в чём фишка. Я могу, конечно, указать вот этот промт и вставить его вот в курсор, и он мне, скорее всего, что-то дадеет и, возможно, сделает всё хорошо. Но потом, когда я его попрошу в рамках этого же контекста или в рамках другого создать по аналогии уже другие автотесты, он может запутаться. И так нельзя делать. Поэтому я, смотрите, вот здесь указываю, что сгенерируй вначале на основе моего описания документ и запиши wordmap MD. Пошаговый план выполнения работы от нуля и до полностью работающих автотестов. На данном этапе мы говорим о автоматизации тестирования API через swager исключительно. Используя Markдаун разметку и чекбоксы для создания плана. Используя русский язык. Вот здесь почему я заостряю внимание вот на этом пункте. На данном этапе мы говорим об автоматизации тестирования опять через swagгер исключительно. Видите, у меня вот правило в QA инженере, что мы используем селенид object и так далее, чтобы он именно понимал, что вот сейчас мы используем именно Rшу и используем API и автотестим именно API.

Так, ну, вроде мы подготовили. Теперь смотрите, перед этим давайте я создам, если у меня его нет, но, по-моему, он у меня есть. Сейчас давайте вспомню. Да, у меня есть roadmap MD, и он у меня пустой. Вот я прямо создам вот такой файл пустой. И вот тоже я его здесь создам. Doc, new file. New file. И test cases md. Test cases wager md. Всё. И теперь смотрите, я прямо копирую вот этот вот промпт, создаю нового агента и указываю ему этот промт. Переключаюсь в эдир. И теперь давайте, чтобы курсор у нас более чётче отработал, мы в контексте мы передадим те файлы, на которые ему стоит обратить более пристальное внимание. Мы передадим ему вот эти вот файлы. Давайте даже вот вот здесь мы сейчас через ставим roadmap MD. Дальше мы ему передадим Cases MD. Дальше мы ему передадим прямо вот всю папочку вот этудок на всякий пожарный add dir directory to cursor. Вот так вот. И на всякий случай мы прямо передадим вот конкретный файл, в котором у нас лежат все наши методы, описанные в свагере. Так, addд. Всё, в целом, по-моему, мы всё сделали. Вот этого нам достаточно. Мы в режиме агента. И теперь о'кей. Давайте попробуем. Теперь ждём, что же у нас получится. Видите, он пишет, что в контекст добавлены вот эти все наши правила. Нам не нужно дополнительно их добавлять в контекст за счёт нашего промтаются. Создаю roadmap для автоматизациитестов на основе swager документации. И давайте мы сразу п и посмотрим наш roadmap. Roadmapзация опять тестирова на основе Sвагер. Общая цель проекта покрытие автотестами все методы из файла IPcs, находящего в папке окей. Подготовка инфраструктуры промокция. Анализ Вагер, документация. Изучить структуру файла. Проанализировать раздел промо определить параметры запросов, схемы ответов и кодустатов для методов раздела промо. Создание тесткейсов для раздела промо. Создать файл. Разработать тесткейсы. Ага. Ага. Позитивные сценарии, проверка всех. Проверка погинации, негативные сценарии, позитивные. Проверка кригативное. Задокументирова результат для каждого теста. Дальше проверка и доработка. Проверить наличие метода при необходимости. О'кей. Дальше реализация автотестов. Этап два. Создание тестового класса. Реализация тестов. И окей. О'кей. Реализация негативных тестов. Реализация раздела. Дальше уже масштабирование, ставить список для всех разделов. О'кей. О'кей. О'кей. В общем, такой крутой крутой план, крутой дмаap. И давайте теперь мы ему напишем, чтобы он реализовал пока что Давайте этап один. Теперь реализуй этап один. Этап один из Road Roadmap MD. Давайте чуть-чуть подвину курсор, чтобы было видно. T из Roadmap. Так, погнали. Дальше он изучает Roadmap, что ему нужно делать, и пойдёт создавать мне тесткейсы. Так, я вижу, что он вот создаёт уже различные тесткейсы. После того, как он это закончит сделать, вот здесь в списке Wagermd, у меня появится список. Ейс он завершил. Видите, дальше он приступил к другому классу. Угу. Дополняет APCOR request. И видите, я вижу, что вот этот уже APCOR request с дополнительными методами, make delete request, видите, make delete requestquery param и так далее, заполняется согласно моему правилу по Java документации. Вот поэтому видите Java doc rule. И вот как раз он автоматом мне прописывает в виде Java doc, документирует все методы, и это очень хорошо. Дальше он, видимо, всё сделал и теперь помечает пункты в ранмапе. Теперь вот смотрите, да, вот он уже показал, что вот сделал вот это, вот это, вот это. Давайте теперь cases на основе swager документации посмотрим. Здесь вам, конечно же, как-то строчком по-хорошему нужно проверить все тесткейсы. Действительно ли они у нас написаны как надо? И давайте вот это посмотрим. Получение списка промоакций. Позитивный безфильтр get промо. После для авторизован с помощью с роль поставщик отправить getзапрос. Ожидаемый результат статус код 200. Success. Массив не пустой. И объект подинации присутствует. Переверяем мы поля bodyди data. Дальше смотрите, он придумал фильтрацию по названию. Сделать пользователь авторизован с поставщик. Тестовые данные, блинчики. Правильно. Get запрос. Ага. В результате присутствует промакци с указанием названия. Проверяемые поля. О'кей. Фильтрация по технологу. Фильтрация по диапазону дат. Ага. Видите, он указывает дату, шаги и возвращается только промокацию в указанном диапазоне дат. Угу. Интересно. Да. Да. Ну вот вам нужно обязательно все вот эти тесткейсы проверить, дать, приревьюить как тестровщику и сказать, корректные они или нет. прямо все изменения. Теперь давайте посмотрим Wordmap. Вдмапе мы тоже нажмём на Keep All и посмотрим, что вот в Брдмапе у нас отметились вот эти вот пункты, вот эти вот пункты, вот эти вот пункты. И да, и вот у нас этап один полностью весь сделался. Давайте мы можем вот сейчас в среду разработки в идея зайти и посмотреть наш методко request. И да, мы видим, видите, добавились новые методы. Никакие дополнительные абстракции не добавились. Добавились только вот made request pery par и так далее. В общем, новые методы MP, MG, Mate Delete и так далее. И всё это автоматом задокументировалось за счёт наших правил.

Так, теперь в целом меня всё устраивает. Естественно, вам нужно будет на реальном проекте всё это проверить. Давайте посмотрим в начале этап второй. Создание тестового класса, да, только для промо. Видите, реализация тестов для GETпрома, да, реализация тестов для GET номенклатур, да, для второго метода. Видите, у нас в Свагере, вот здесь, если мы посмотрим, два метода AP промо и AP про Promo Nomменклатурs. Всё. Реализация негативных тестов, финализация раздела промо. Всё, да, меня полностью устраивает вот этот план. Теперь я пишу. Теперь реализуй этап два согласнопу. Roadmap MD. Всё, теперь мы давайте нажимаем на Enter. Кстати, я вам не сказал, но здесь была иконочка записи аудио микрофончика. Можно не писать весь текст, а просто включить, соответственно, микрофон и записывать всё голосом. И курсор будет делать всё, что вы ему запишите. Видите, снова он мне пишет, что в контекст добавлены такие-то правила и так далее. Начиная реализацию этапа два. И теперь нам остаётся только ждать, когда он напишет код.

О'кей, давайте сразу нажмём и посмотрим, что у нас выполнил курсор. Давайте вначале взглянем на Roadmap. Мы видим, что все пункты он у нас выполнил по второму этапу. Давайте теперь посмотрим наши тесты. Давайте посмотрим их здесь. Промо IP. И мы видим, что вот он у нас реализовал огромное количество тестов. В целом, как мы видим, все они были реализованы ПТЗ. Вот точно также он везде заюзал make, make и так далее. везде указал вот этот вот спецификацию sulplyer вот с этим вот технологом. Вот. И нигде он не отошёл. Везде он проверяет successс, везде он проверяет различные поля. В каждом тесте он проверяет разные поля. И давайте попросим курсор запустить все наши тесты. Запусти все автотесты по рома. О'кей. Он запускает. Сейчас наверняка часть тестов упадёт, и он пофиксит их. Два теста упали. Проверяю детали и исправляю. О'кей, исправим детали. Нажимаем Run. Естественно, вам нужно, если вы будете работать с реальным проектом, естественно, вам нужно перепроверить тщательно все эти тесты, отревьюить, возможно, улучшить какие-то промты и так далее, дописать. Это суперважно сделать. Исправляе два пау тест, исправляе начить данных перед проверкой полей. Ждём. Исправлены проблемные тесты. Можно, нужно обязательно посмотреть, какие тесты исправлены, что он там добавил, почему они упали сейчас, чтобы не было такого, что тесты реально падают, а он делает так, чтобы они просто не падали. Запускаю. О'кей. Все тесты прошли. Получаю детальную статистику. О'кей. Проверяешь там отчёт с результатами тестов. Ну, это он уже делает, конечно, лишнее, но ладно. Запускаю тест ещё раз до получения полной статистики. Давайте скипнем этот шаг. Он нам не нужен. Всё, он keep all. И он у нас обновил rootmap. То, что все пункты отмечены. Давайте мы вернёмся в привычную мне среду разработки и снова запустим все тесты локально. И как мы видим, сейчас все тесты у нас проходят, все тесты зелёные.

Теперь смотрите, давайте подумаем вот без текейсов, только опять же на основе славагера, как мы можем вот эти тесты улучшить. И давайте прямо вот здесь в этом окне напишем, можешь ли ты сделать контракт. Контракт тестинг. Тестинг. что у нас возвращается нужная структура и типы согласно согласно свагеру. Можешь это сделать контракт-тестинг, что у нас возвращается нужная структура и типы согласно свагеру. Давайте, наверное, так. Так и оставим. Смотрите, ещё раз мы откроем наш свангер. Мы, получается, что сейчас проверили, что у нас вот куча куча автотестов, куча кейсов вот по вот этим двум методам. Он возвращает, что у нас они все там двухсотые, что везде successцесс по этим разным вариациям тестов. И у нас каждый раз возвращается согласно контракту какое-то поле, и оно не нул. А теперь я хочу проверить, чтобы вообще все поля, которые у нас есть свагеры, которые прописаны контракту, чтобы они именно возвращались, была проверка на то, что возвращается нужный тип, который прописан в свагере. Вот что я хочу сделать. Давайте напишем, что сделай такие дополнительные проверки в этих же автотестах на промо и нажмём Enter. И теперь мы снова ждём. И видите, я уже вижу, что он в целом всё правильно делает. Видите, он теперь, если вот мы так нажмём, он очень быстро делает. Давайте дождёмся после того, как он всё закончит и отредактирует все вот эти вот тесты. Ну давай, о'кей, запусти все тесты, что-то поправь, если вдруг будут какие-то ошибки. Какой-то тест упал, видите? Снова его перезапускаем. Естественно, вам нужно будет перепроверить за иишкой. Это прямо обязательно. Он его тут же поправил. И сейчас мы перезапускаем. Все тесты пришли. Получаю итоговую статистику. Давай это скипнем. О'кей. Давай сразу сделаем кип и вернёмся в наши тесты. Промо IP-тесты. Смотрите, мы видим, что у нас действительно, видите, теперь он стал проверять, вот обращается к прому и проверяет, что всё как раз с вагера, все поля у нас вернулись и что они содержат нужный нам тип. Ну, красота. Запустим эти тесты локально. И они все проходят, да, все зелёные.

И смотрите, что на самом деле ещё мы можем сделать. Мы, по идее, можем сделать, мы проверили, что у нас возвращается вот по контракту всё. Можно также проверить, что все поля, которые возвращаются по контракту, не пустые. Но нам самое главное, да, как-то проверять значение. Нам самое главное проверять значение. Вот это вот, да, то, что конкретное значения. Но здесь нам уже без тесткейсов не обойтись. Если бы у нас были готовые тесткейсы от тестировщиков, то по этим тесткейсам в купе вот с тем, что я вам сейчас показал, ну, написать такие автотесты, сгенерить такие автотесты при помощи курсора будет несложно. Но, допустим, у нас также нет тесткейсов, и мы хотим проверять какие-то значения. Можно в целом сделать знаете что? Сделать так называемое сNпшот-тестирование. Допустим, мы понимаем, что вот этот вот свагер, он у нас сейчас, да, мы можем, допустим, в этом же свагере обращаться к какой-то ручке к проду. И у нас есть тестовый контур, грубо говоря, есть свагер на прод и есть свагер на тестовый контур. И мы понимаем, что в тестовом контуре под капотом подняты какие-нибудь клоны базы данных. И они, допустим, полностью копии продово месячной данности или трёхмесячной давности. И в целом мы можем делать так в самих тестах, вот в этих, вначале обращаться к проду. Вот, допустим, здесь, да, и всё это нагенерить курсором, обращаться к проду, сохранять потом условно вот, допустим, вот здесь и будет, допустим, response prod. И вот здесь мы обратимся к проду и сохраним какой-то результат. Далее мы сделаем вот этот вот запрос, который здесь, и мы обратимся к тестовому свагеру. Response responsтест, допустим, это будет вот так вот. И в конце мы просто сравним, что вот этот респонс прода равен вот этому респонсу с теста, так как мы подразумеваем, что данные с прода и данные с теста должны быть одинаковы, так как к тесту подключена копия базы данных с прода. Можно сделать так. Это если у вас, допустим, такая ситуация, можно сделать по-другому. Можно сделать так, допустим, данные всё-таки разные, но вы понимаете, что сейчас у вас тест-кейсов нет, но вы протыкали весь свагер, и вы понимаете, что сейчас данные возвращаются идеальны. Всё хорошо. Вы можете сделать так называемое сnпшот-тестирование, условно даже давайте спросим это у курсора в режиме Ask. Делать это не будем. Можешь ли ты спшот можешь ли ты сделать спшоттестинг реальный запрос капе смотреть что пришло в ответе использовать эти данные для проверки в тесте курсор яишка будет делать запрос реальный, получать какие-то реальные данные. И эти данные, понимая, что вот это сейчас эталон, будет использовать для проверки в тесте. Она условно вот получит именно вот давайте вернёмся в промотест, получит вот эти значения, блинчики и так далее, и прямо будет их вот так вот и проверять. Вот давайте спросим аишки. Реализация возможна. О'кей. О'кей. Чтобы я применил изменения. Нет, нет, мне это не нужно.

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

А теперь представим ситуацию, что вы, допустим, пилите какой-то свой продукт, не знаю, и у вас нет вообще тестировщиков, и вам нужно как-то это всё тестировать. Или, допустим, у вас вы один-то срощик на проекте, у вас какой-то такой небольшой продукт, ну, как бы маленький, э, автотесты изучать некогда, не хочется, нет времени и так далее. И вы хотите как-то вот вот реализовать вот эту автоматизацию. Не то, что реализовать автоматизацию, вы хотите как-то вот эту рутину, когда вам нужно проверять регресс каждый раз руками, как-то передать роботам, но при этом не хотите изучать автотесты. И давайте мы сейчас здесь создадим файл, назовём его testes testas Google.m. И давайте здесь создадим ещё один файл и назовём его барт Google. MD cases Google MD и Breort Google MD. Давайте создадим с новым агентом и попросим Ишку написать мне тесткейсы на Google. Напиши мне. Представьте, да, что вот этот сайт небольшой, небольшая компания, в которой вы работаете - это компания Google. Напиши кейсы на поиск google.ru. Используй, используй техники тест дизайна. позитивные и негативные проверки. Напиши не больше двадцати кейсов и результат сохрани в с кейсе с Google MD. О'кей. Так, погнали. И ждём теперь. Ждём, когда он нам напишет скейсы. О'кей. Так, негативные. Ну, давайте сразу примем. Посмотрим. Медиум, граничные значения на главной странице, поисковый запрос. Ну, в общем, да, что видим, что Ишка нам написала тесткейсы по всем канонам, правильно их оформила, применила различные техники тест-дизайна, разные негативные сценарии и так далее. И теперь давайте попросим Иишку всё это протестировать. Протестируй кейсы. из файла при помощи Play WR MCP. Помните, я рассказывал про Playri? И видите, вот здесь у меня, давайте я вот так вот открою. И вот здесь, видите, у меня установлено MCP плейрайта. при помощи Playri MCP результаты результаты сохрани в в бакрепорт Google MD, вернее, не результат, а давай найденные баги, если они вдруг будут. Вдруг мы найдём сейчас в Гугле баг найдены баги. Сохрани в багрепорт Google MD. О'кей, погнали. И теперь смотрите, что у нас произойдёт. Нажимаем Enter. И мы видим, что у нас открывается браузер. Я ничего не делаю, руки у меня здесь. И он автоматом вводит под тесткейсом различные штуки и проверяет. У меня поиск в Гугле вводит что-то. В принципе, вы можете также при помощи MCP где-то у себя хранить тесткейсы в MD формате. Конечно, лучше их потом переносить в какую-то систему TOOPS, но это несложно сделать. Но в целом, если у вас какой-то небольшой проект и вы там один тестировщик, то вполне можно обойтись и так вот таким образом через MCP проводить тестирование каких-то какие-то регрессионные тесткейсы написать опять же при помощи курсора, потом проводить само тестирование, запускать вот так вот браузер опять же при помощи курсора и MCP плейрайта. В целом это вполне допустимо. Видите, он сейчас пробует, видимо, какие-то уязимости найти. Вставляет, видите, але джаваскриптовский. О'кей. Видите, всё, он у нас Ага. Пас найден баг. Давайте сохраним всё и посмотрим, что он у нас нашёл. Багрепорт. А результат тестирования. Протестированы пять из 20 тесткейсов, 25% покрытия на найденные баги. Почему, кстати, только пять? Ну ладно, о'кей. 5к 5. Ну, в целом вы понимаете, да, что можно протестировать всё. Поиск на русском языке, оператор сайт, автодополнение, простой запрос и, э, найден баг. Он нашёл какой-то баг. Давайте посмотрим, что за баг он нашёл. Найденные баги, неэкранированный HTML-код в заголовке страницы при XS попытке открыт. При вводе XS попытки в поиску срок и выполнении поиска в загловке отображается неэкранированный HTML-код вместо безопасного текстового представления. Открыть главную страницу, ввести в поисковую строку, нажать Enter, проверить заголовок страницы в браузере. Гловок страницы. Ага. HTMLX забражается как тесто. Скрипт не выполняется. На странице результаты входа забражается корректно. Hдам результат должен содержать. А, о'кей. Ну, типа, да, должно экранироваться. Ну, о'кей. О'кей. Ладно. В общем, как-то так. Можно проводить визуальное тестирование при помощи курсора и при помощи MCP PlayR.

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