Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы следите за сферой AI-ассистентов для программирования, то, скорее всего, заметили, насколько быстро всё развивается. Новые модели выходят каждый месяц, и все пытаются выявить «правильный способ» работы с этими инструментами. Я провёл последние пару месяцев, создавая тесты на Playwright с помощью Cursor, и, честно говоря, прошел через множество проб и ошибок. Некоторые вещи работали отлично, другие… не очень.

Я решил собрать всё, чему научился, в этом посте. Давайте разберёмся.

1. Оставайтесь в режиме "Auto"

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

Я обнаружил, что режим "auto", где Cursor сам выбирает модель, работает очень хорошо. Не тратится ментальная энергия на выбор модели под задачу. Сосредоточьтесь на написании хороших промптов, а инструмент пусть делает своё дело.

2. Используйте project rules для описания приложения

Это, пожалуй, самый важный совет в этом списке. Project rules в Cursor автоматически добавляются в контекст, то есть всегда доступны при генерации кода.

Я использую правила, чтобы описать:

• архитектуру приложения
• подход и философию тестирования
• скрипты базы данных и команды настройки
• команды запуска тестов
• конвенции селекторов (data-testid, role-селекторы и т.д.)
• предпочтения по стилю кода
• структуру проекта и расположение файлов.

Думайте о project rules как о руководстве, которое AI-ассистент читает перед началом работы. Чем лучше руководство, тем лучше результат.

Также можно разбить правила на отдельные файлы в папке .cursor/rules. Тогда каждый тестовый файл получает ровно тот контекст, который ему нужен.

.cursor
└── rules
├── selectors.mdc
├── test-structure.mdc
└── database.mdc

Можно также настраивать правила через glob для конкретных .spec.ts файлов и ссылаться на файлы вроде конфигурации Playwright.

3. Не скачивайте чужие правила

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

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

Создавайте правила органично. Когда Cursor ошибается — возвращайтесь к правилам и корректируйте их, чтобы ошибка не повторялась. Если приходится давать одни и те же инструкции снова и снова — превращайте их в правило.

4. Создавайте custom commands

Как и rules, custom commands задают рамки и ограничения для AI-агента. Но цель у них немного другая. Обычно они описывают конкретный workflow или последовательность шагов для выполнения задачи.

Например, если тесты следуют паттерну Arrange - Act - Assert, можно создать команду, которая описывает, как этому паттерну следовать.

Custom commands легко создаются через ввод / в чате. Они сохраняются в папке .cursor/commands. Можно даже попросить агента сгенерировать команду и доработать её под свой стиль кода.

5. Ссылайтесь на код приложения

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

И здесь AI может сильно помочь. Допустим, не удаётся найти файл компонента для элемента, который нужен в тесте. Откройте DevTools в браузере, скопируйте элемент из панели Elements и вставьте в чат Cursor. Поскольку Cursor индексирует исходный код, можно попросить объяснить, что это, или помочь найти нужный файл и селектор. После этого добавить data-атрибут — дело техники.

Дополнительный совет: используйте имена папок в промптах вместо синтаксиса @folderName или добавления папок в чат. Это не даст Cursor читать все файлы в папке, что перегружает контекст и увеличивает вероятность ошибок.

6. Скриншоты могут быть полезнее текста

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

AI отлично связывает визуальный контекст с кодом. Когда есть:

• «Вот страница» (скриншот)
• «Вот тест» (ссылка на файл)
• «Вот как страница выглядит при падении теста» (скриншот),

AI начинает точно понимать задачу. Это как разница между описанием комнаты по телефону и показом фотографии.

7. Учитесь эффективно использовать Playwright MCP

Если использовать Playwright MCP для генерации тестов, результаты могут быть странными и медленными. У меня не получилось добиться хороших результатов по сравнению с codegen.

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

Чтобы отладить падающий тест, можно начать с простого промпта:

1  "This test fails on line 6. Open the browser, run the test,

2  and tell me what's wrong."

Фраза "open the browser" даёт понять AI, что нужно использовать Playwright MCP.

Но можно идти дальше и комбинировать MCP. Например, использовать GitHub MCP, чтобы получить последний прогон CI, выбрать упавший тест, а затем запустить Playwright MCP для локальной отладки. Скриншоты, трейсы и снапшоты дают AI нужный контекст.

8. Выходите за пределы Cursor для планирования

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

Например, я использую repomix, чтобы собрать код в XML, а затем вставляю его в Gemini или Claude, чтобы:

• создавать project rules
• проектировать workflow
• генерировать промпты для тест-планов
• создавать диаграммы mermaid для архитектуры тестов

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

9. Тестирование сейчас важнее, чем когда-либо

Это не совсем совет про Cursor, но об этом нужно сказать.

С ростом «vibe coding»-платформ, где AI генерирует целые приложения, тестирование становится критически важным. Без тестирования невозможно получить качественный софт. Код можно генерировать с огромной скоростью, но без проверки это просто быстрый путь к сломанной системе.

В nut.new мы серьёзно относимся не только к написанию full-stack приложений, но и к запуску тестов и проверке функциональности. AI может писать код, но именно тесты дают уверенность для релиза.

Если используете AI для написания кода, используйте его и для написания тестов. Иначе никак.

10. Думайте как экспериментатор

То, что я дал вам 9 советов, не значит, что всё это вам подойдёт. Я постоянно подстраиваю процесс под себя. Здесь очень помогает мышление тестировщика — пробовать новое, смотреть, что работает, а что нет.

Надеюсь, это было вам полезным. Если есть свои советы по работе с Cursor и Playwright — напишите в Twitter, LinkedIn или присоединяйтесь к моему Discord-сообществу, где мы это обсуждаем.

И если это оказалось полезным, поделитесь с командой — скорее всего, они сталкиваются с теми же проблемами.

Удачного тестирования! 

Обсудить в форуме