Как я могу использовать свои собственные составные части в тесте по драматургии?
Я заменил пинию на собственный составной «useSettings». В моих драматургических тестах я смог получить доступ к Пинии следующим образом:
window.__NUXT__?.pinia.myStore
Теперь, когда я пытаюсь использовать компоновку внутри своих тестов, я получаю сообщение об ошибке «useSettings не определено».
Как я могу его импортировать? 🤔
Вариант использования прост:
Чтобы решить, должно ли мое приложение отображать баннер cookie, у меня есть переменная «xIpContinent». Раньше он находился в магазине «Пиния», и я мог получить к нему доступ через драматурга.
Теперь эта переменная предоставляется компонуемым объектом, который я не могу использовать внутри своего теста и не знаю, как получить к нему доступ.
Обновление после комментариев:
Хорошо, я с вами по поводу независимого от платформы тестирования в целом. Однако в моем случае использования требуется некоторая дополнительная информация.
В зависимости от IP-адреса клиента отображается (или нет) баннер cookie. Чтобы проверить это поведение, мне нужно знать, ожидать ли баннер cookie или нет. Только мое приложение знает IP-адрес клиента.
Кроме того, на каждый последующий тест влияет баннер cookie, который довольно агрессивен: пока он отображается, нажимать на другие кнопки невозможно.
Если вы будете иметь дело с этим, не зная, чего ожидать, это определенно увеличит сложность моих тестов E2E 🤔
Ты прав. Я обновил вопрос.
Спасибо. После обновления мой комментарий по-прежнему актуален: вы не хотите тестировать подобные вещи с помощью Playwright. Проверьте пользовательский интерфейс — нажмите кнопку и убедитесь, что на экране что-то появилось! Независимо от того, было ли это достигнуто с помощью Vue, React, Angular, SQL, Mongo, Pinia, компонуемых объектов, перехватчиков или COBOL, совершенно не имеет значения для тестов E2E. Я все же предлагаю предоставить более подробную информацию: какую страницу вы тестируете и какое видимое для пользователя поведение вы пытаетесь протестировать?
Тестируйте интерфейс, а не реализацию. Поскольку это может измениться в будущем, но это не ваша забота, пока это не влияет на поведение пользователя, то есть на пользовательский интерфейс.
Ответы 1
Не. Playwright спроектирован так, чтобы быть независимым от фреймворка и не тестировать детали реализации . Вы хотите протестировать видимое пользователю поведение . Идея состоит в том, чтобы манипулировать приложением так, как это делают ваши пользователи, щелкая и вводя текст в пользовательский интерфейс и утверждая наблюдаемые изменения текста, а также наличие или отсутствие элементов на экране. Ваши пользователи не будут проверять переменные окна или открывать консоль браузера, поэтому и ваши тесты не должны этого делать. Ваших пользователей не волнуют переменные, составные элементы, хранилища, CSS-классы, XPath или библиотеки JavaScript, и ваши тесты тоже не должны.
Модульные тесты, а не сквозные тесты, учитывают используемую библиотеку пользовательского интерфейса, а также параметры и значения рендеринга, возвращаемые компонентами. Модульное тестирование также учитывает решения по управлению состоянием и, скорее всего, будет имитировать хранилища и сетевые вызовы.
Но даже в модульных тестах локальные переменные, составные элементы и перехватчики являются частными для компонента и недоступны другим компонентам, а также вашим тестам, и поэтому по-прежнему являются деталями реализации. Не тестируйте их напрямую — манипулируйте компонентом так, как это делает пользователь (клиент-программист, компонент, передающий реквизиты, внедряющий сервис, или человек-пользователь интерфейса, а не тестовый пользователь).
Это ничем не отличается от тестирования функции или утилиты службы Vanilla JS. Вы передаете параметры и утверждаете возвращаемое значение. Все локальные переменные, которые помогают получить этот результат, неизвестны. Нас не волнует, как функция (или компонент в модульном тесте пользовательского интерфейса) выполняет свою работу, нас волнует только то, чтобы она выполняла свою работу правильно. Линтеры и инструменты статического анализа проверяют соглашения об именах переменных и сложность внутренних функций, а не модульные тесты.
Но модульные тесты — это совсем другая история: в E2E-тестах составные элементы совершенно не имеют значения и не должны тестироваться, потому что они делают ваши тесты хрупкими, тестируют не тот уровень абстракции, выполняются гораздо медленнее, чем модульные тесты, и не дают никаких результатов. уверенность в том, что приложение работает на пользователя. Чем больше «черного ящика» вы сможете написать в своих E2E-тестах, тем меньше времени вам придется тратить на исправление неработающих тестов, устранение нестабильностей и недостающих ошибок, которые могут видеть ваши пользователи.
Если вы пишете свои тесты, следуя лучшим практикам Playwright , вы сможете менять решения по управлению состоянием или даже фреймворки пользовательского интерфейса без необходимости менять какие-либо тесты. На практике это не всегда возможно, но чем больше вы сможете принять эту философию, тем лучше. Если бы вы следовали этим принципам с самого начала, вам бы никогда не пришлось задавать здесь этот вопрос! (Но никогда не поздно прекратить тестирование деталей реализации, теперь, когда вы на собственном опыте столкнулись с проблемами, вызванными этим).
Кстати, не позволяйте проблемам покрытия вызвать у вас желание протестировать детали реализации. Вы можете измерять покрытие транзитивно, не зная деталей реализации: нажатие кнопки запускает обратный вызов и изменение состояния, обеспечивая покрытие.
Спасибо за краткий ответ. Я обновил свой вопрос, проливая некоторый свет на мой конкретный тест.
Без конкретного примера я не вижу, как баннер cookie что-либо меняет. Почему бы просто не заблокировать элемент баннера cookie для всех тестов, за исключением одного или двух, где вы хотите его протестировать? И в этих тестах вы определенно не хотите тестировать компоновку, поскольку это не дает вам уверенности, что баннер действительно отображается пользователю, а только в том, что он находится в состоянии. Вероятно, вы бы использовали что-то вроде await expect(page.locator("#cookie-banner")).toBeVisible() (или, если возможно, используйте getByRole на какой-нибудь уникальной кнопке и тексте на баннере).
Вы также можете отклонить его в тесте beforeEach или кэшировать его в userDataDir и отклонить с помощью функции настройки, которая запускается перед всеми тестами, за исключением тех, в которых вы непосредственно тестируете баннер.
Сделав шаг назад, Playwright — это библиотека тестирования E2E. Философия заключается в том, что вы взаимодействуете с действиями, видимыми пользователем, и тестируете свою страницу так, как это делает человек. Люди, посещающие ваш сайт, не знают, что такое Пиния, и не манипулируют ею напрямую. Это деталь реализации — манипулируйте пользовательским интерфейсом, и если получится управлять состоянием с помощью Pinia, отлично, но если вы проведете рефакторинг на другое решение по управлению состоянием, как вы это сделали, ваши тесты не должны измениться. Playwright работает в Node, поэтому не импортируйте окно в Node. Короче говоря: это может быть проблема XY, которую можно решить, предоставив контекст и минимальный воспроизводимый пример.