Автор стремится писать фронтенд на JavaScript, не полагаясь на Node.js. Серьезной проблемой стало отсутствие эффективных методов тестирования фронтенд-кода. Предыдущие попытки с Playwright были признаны медленными и требовали Node.js. Для решения этой проблемы автор изучил возможность запуска тестов непосредственно во вкладке браузера, вдохновившись работой Алекса Чана над минималистичным фреймворком для юнит-тестирования в браузере. Хотя подход Чана был сосредоточен на юнит-тестах, автор стремился проводить сквозные интеграционные тесты для Vue-компонентов без процесса сборки Node.js.Автор использовал QUnit в качестве фреймворка для тестирования, оценив его кнопку "повторить тест" для отладки. Процесс включал настройку Vue-компонентов путем их глобального экспорта и создание функции mountComponent для их рендеринга в невидимом, скрытом от страницы div. Данные для тестов управлялись путем сброса базы данных посредством POST-запроса на выделенный конечный пункт. Базовый тест затем рендерил компонент и проверял его содержимое.Основные возникшие проблемы включали ожидание завершения асинхронных операций, что привело к разработке функции waitFor(). Определение правильного элемента или условия для ожидания оказалось сложным, что вызвало предложения по рефакторингу приложения для повышения надежности. Автор также экспериментировал с добавлением CSS-классов для идентификации элементов, отмечая, что библиотеки, такие как Testing Library, рекомендуют более доступные подходы.Обработка форм представляла трудности, поскольку простое присвоение значений было недостаточным; требовалось вызывать соответствующие DOM-события. Это подчеркнуло, почему библиотеки для тестирования пользовательского интерфейса могут упростить такие задачи. Покрытие тестами было частично оценено с помощью встроенных инструментов разработчика Chrome, хотя процесс требовал специфических настроек и действий для работы с бандлированным JavaScript.Несмотря на кривую обучения, автор нашел этот опыт приятным и выразил оптимизм по поводу создания надежного набора тестов для своих фронтенд-проектов. Они также рассматривают дальнейшее изучение библиотек, таких как Testing Library, которая предлагает UMD-сборку, совместимую с выполнением только в браузере, и размышляют о том, как интегрировать тесты, ориентированные на браузер, в CI-среды.
mountComponentдля их рендеринга в невидимом, скрытом от страницы div. Данные для тестов управлялись путем сброса базы данных посредством POST-запроса на выделенный конечный пункт. Базовый тест затем рендерил компонент и проверял его содержимое.Основные возникшие проблемы включали ожидание завершения асинхронных операций, что привело к разработке функцииwaitFor(). Определение правильного элемента или условия для ожидания оказалось сложным, что вызвало предложения по рефакторингу приложения для повышения надежности. Автор также экспериментировал с добавлением CSS-классов для идентификации элементов, отмечая, что библиотеки, такие как Testing Library, рекомендуют более доступные подходы.Обработка форм представляла трудности, поскольку простое присвоение значений было недостаточным; требовалось вызывать соответствующие DOM-события. Это подчеркнуло, почему библиотеки для тестирования пользовательского интерфейса могут упростить такие задачи. Покрытие тестами было частично оценено с помощью встроенных инструментов разработчика Chrome, хотя процесс требовал специфических настроек и действий для работы с бандлированным JavaScript.Несмотря на кривую обучения, автор нашел этот опыт приятным и выразил оптимизм по поводу создания надежного набора тестов для своих фронтенд-проектов. Они также рассматривают дальнейшее изучение библиотек, таких как Testing Library, которая предлагает UMD-сборку, совместимую с выполнением только в браузере, и размышляют о том, как интегрировать тесты, ориентированные на браузер, в CI-среды.