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

Начинают с чтения самого падения. Vitest печатает Expected и Received - что ожидалось и что пришло, - и строку, на которой assert не сошёлся. Часто этого уже достаточно: видно, что число на единицу меньше, что в объекте лишнее поле, что вместо массива пришёл undefined. Стек вызовов ведёт к месту в коде под тестом. Прежде чем звать тяжёлые инструменты, стоит внимательно прочитать то, что раннер уже сказал.

Для наглядной картины есть Vitest UI - дашборд, который включают флагом --ui из пакета @vitest/ui. Он показывает дерево файлов и тестов, статусы, вывод каждого теста, граф модулей и позволяет фильтровать и перезапускать. На большом наборе это удобнее сплошной терминальной простыни: видно, какие файлы задеты, как связаны модули и что именно печатал упавший тест, без прокрутки логов.

Когда тест-файл большой, поле зрения сужают. test.only оставляет в прогоне единственный тест, describe.only - единственную группу; test.skip временно выключает, а test.todo помечает ещё не написанное. Это отсекает шум и даёт гонять только подозрительное. Важно не забыть снять only перед коммитом - иначе в CI молча выполнится один тест вместо всех, и набор перестанет что-либо стеречь.

Сужать можно и не трогая код. Флаг -t (--testNamePattern) оставляет тесты, чьё имя подходит под шаблон, а указание пути файла ограничивает прогон одним файлом. Вместе с watch это даёт быструю петлю: правишь - мгновенно видишь результат по одному тесту, не гоняя весь набор. Такой точечный запуск - основной способ держать цикл отладки коротким, пока причина не локализована.

Для настоящей отладки подключают дебаггер. Vitest запускают с --inspect-brk и обязательно с --no-file-parallelism: параллельные воркеры и пошаговая отладка несовместимы, файлы должны идти по одному. Тогда к процессу цепляют инспектор - из редактора или Chrome DevTools, - ставят точку останова и идут по шагам, глядя на реальные значения переменных вместо догадок по логам. Это дороже print-отладки, но точнее на запутанном баге.