Некоторые планы тестов неисправны ещё до запуска.
Некорректный шаг или неопределённый селектор не приводят к чистому сбою — они тратят прогон впустую, пока вы это выясняете. testsprite test lint <planFile> сначала проверяет структуру плана тестов, так что вы ловите проблему до того, как потратите на неё время или кредиты.
Встроено в тот же CLI, которым вы уже пользуетесь
Ловит некорректные шаги
testsprite test lint <planFile> проверяет каждый шаг действия и проверки в плане тестов на структурные проблемы — прежде чем любой из них запустится на вашем реальном окружении.
Отмечает неоднозначные проверки
Проверка без чёткой цели — это проблема, которую вы не захотите обнаружить посреди прогона. Линтер ловит её, пока план ещё просто JSON-файл.
Находит отсутствующие селекторы
Шаг, ссылающийся на селектор, никогда не определённый в плане, отмечается сразу, а не всплывает позже как запутанный сбой.
Работает с любым планом тестов
Линтер запускается на любом JSON-файле плана тестов — сгенерированном TestSprite или отредактированном вручную, — так что он подходит независимо от того, как ваши планы создаются на самом деле.
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✗ 2 issues found
- step 3: assertion is missing a clear target
- step 7: selector not defined in this plan
→ fix these before running the plan
$ testsprite test lint test-plan.json
Checking test-plan.json for structural problems...
✓ no structural problems found
Не тратьте прогон на план, который изначально не мог сработать
План тестов с некорректным шагом или неопределённым селектором падает не потому, что сломан ваш продукт, — он падает потому, что структурная проблема есть в самом плане. Линтинг ловит это заранее, до того, как это стоит вам прогона.
Создано для планов тестов, которые редактируют вручную
Работает с любым планом тестов
Сгенерирован он или отредактирован — не важно: test lint запускается на любом JSON-файле плана тестов в вашем проекте.
Встраивается обратно в цикл
Агент, генерирующий или редактирующий план тестов, может вызвать test lint перед передачей его в test run, ловя проблемы, пока их ещё дёшево исправить.
Бесплатная версия для сообщества
Предлагаем бесплатную версию для сообщества, делая наш продукт доступным для всех.
Работает в связке с запуском
Запускайте testsprite test lint прямо перед testsprite test run, чтобы структурная проблема никогда не получила шанс сжечь реальный прогон.
Нам доверяют компании по всему миру
"TestSprite предлагает богатую генерацию тест-кейсов, четкую структуру и легко читаемый код. Он также поддерживает простую онлайн-отладку с возможностью быстрого расширения путем генерации новых тест-кейсов."
"Автоматизация TestSprite помогает нам сократить огромное количество ручной работы. Разработчики могут легко обнаруживать и устранять ошибки на более ранних этапах процесса разработки."
Часто задаваемые вопросы
Что именно проверяет testsprite test lint?
Он проверяет структуру JSON-файла плана тестов — такие вещи, как некорректные шаги действия или проверки, проверки без чёткой цели и селекторы, на которые есть ссылки, но которые нигде не определены, — прежде чем план запустится на вашем реальном окружении.
Чем это отличается от простого запуска плана тестов и наблюдения за тем, что произойдёт?
Запуск плана тратит время и кредиты на то, чтобы выяснить, что сам план был неисправен. Линтинг находит те же структурные проблемы только по JSON-файлу, до того как что-либо выполнится.
Работает ли это с планами тестов, которые я написал или отредактировал вручную, а не только со сгенерированными?
Да — test lint запускается на любом JSON-файле плана тестов, независимо от того, пришёл ли он из TestSprite или был отредактирован напрямую.
Что делать, когда test lint находит проблему?
Исправьте отмеченный шаг в JSON-файле плана тестов и снова прогоните линтер. Чистый проход означает, что план структурно исправен, прежде чем вы потратите на него прогон.
Стоит ли запускать test lint каждый раз, даже на планах, которые я уже запускал раньше?
Это дёшево запускать, и он ловит проблемы, внесённые ручными правками, так что запускать его перед test run — разумная привычка, особенно в CI.