Сообщения

End-to-End testing of a Next.js application using Playwright and MSW. Continue

This article is a continuation of the previous one «End-to-End Testing of a Next.js Application Using Playwright and MSW» , and aims to explain why we ultimately opt to use a separate mock server despite the fact that it’s possible to mock current requests directly within the test environment. Initially, using the @mswjs/http-middleware library to start a separate server wasn't part of the plan. The idea was to hook into the existing server within the test environment. To do this, we add a .env.test file with the following contents: APP_ENV=test And in the main layout file app/layout.tsx , we’ll use this environment variable to determine whether the mock server should be enabled or not: import { server } from '@/mocks/server'; // only TEST ENV: run server.listen for e2e-testing if (process.env.APP_ENV === 'test') {     server.listen({         onUnhandledRequest(request) {           ...

e2e тестирование nextsj приложения с playwright & msw. Продолжение

Эта статья продолжает предыдущую «e2e тестирование nextsj приложения с playwright & msw»  , вернее поясняет почему мы приходим к варианту работы с отдельным сервером, тогда как можно замокать текущие запросы в текущем окружении. Изначально не предполагалось использовать  @mswjs/http-middleware библиотеку для запуска отдельного сервера, а слушать текущий сервер в тестовом окружении. Для этого добавим файл  .env.test со следующим содержимым: APP_ENV=test А в главном лайауте  app/layout.tsx  будем использовать эту переменную окружения чтобы определить слушать ли сервер или нет: import { server } from '@/mocks/server'; // only TEST ENV: run server.listen for e2e-testing if (process.env.APP_ENV === 'test') {     server.listen({         onUnhandledRequest(request) {             console.log('Unhandled %s %s', request.method, request.url);    ...

End-to-End testing of a Next.js application using Playwright and MSW

Server and Client Components in Next.js Before writing end-to-end tests, let’s first understand how Next.js works and what specific features it introduces - namely, the concept of server and client components. In the past, we typically had only client-side JavaScript and separate code that ran on the server. Next.js revolutionized the frontend world by merging these two concepts into a unified system, allowing developers to seamlessly transition between components. The only real distinction now lies in explicitly declaring «use client» at the top of files that need to run in the browser. This can become a source of confusion if you're not familiar with how both types of components work. By default, all components in Next.js are server components and are rendered on the server. This comes with both advantages and limitations. For example, server components can access data directly, work with environment variables, and securely use access tokens. On the flip side, they cannot use Re...

e2e тестирование nextsj приложения с playwright & msw

Серверные и клиентские компоненты в nextjs Прежде, чем писать e2e тесты, давайте разберемся с nextjs и теми особенностями, которые он дает, а именно — что такое серверные и клиентские компоненты. Раньше у нас был только клиентский js, и отдельно код, который запускается на сервере. Nextjs перевернул мир фронтэнда, совместив эти две концепции в один, сделав переход для разработчика от одних компонент к другим практически бесшовным. Вся разница заключается в указании «use client» в файлах, которые должны выполняться на клиенте. И это может создать путаницу, если не понимать принцип как работают оба вида компонент. Изначально все компоненты считаются серверными и рендерятся на сервере, они имеют как преимущества, так и ряд ограничений. Например, они могут напрямую обращаться к данным, а также env-переменным и токенам доступа. Но с другой стороны не могут выполнять хуки или производить интеративные клиентские события, у них нет доступа к браузерному API. Как проверить где выполяется компо...

Accessibility for MUI components

Introduction In the early days of the web, websites were a vast playground for creativity and experimentation. Everyone wanted to stand out, craft a unique design, and develop custom form fields, menus, and pop-ups that would make their site memorable. Unexpected background music, animations, videos — everything was fair game to impress users. Developers created their own UI elements, some successful, some not so much. Naturally, as the web grew, there was a need to bring order to this chaos and make websites more user-friendly. That’s where W3C came in, an organization that establishes web standards, including accessibility guidelines . Accessibility isn't just for people with disabilities (such as those with visual or hearing impairments), as many tend to assume and therefore, often ignore. For me, accessibility is about courtesy in web development. A website should help users accomplish their goals — whether it's logging in, filling out a form, or finding information — rathe...

Доступность для mui компонент

Введение На заре становления веба сайты были огромным полем для творчества и экспериментов. Каждый хотел выделиться на фоне остальных, придумать уникальный дизайн, разработать не похожие на другие поля формы, меню, попапы, чтобы сайт запомнился пользователям. Неожиданные музыкальные вставки, анимации, видео, всё, чтобы впечатлить. Разработчики изобретали свои элементы управления, как удачные, так и нет. Неудивтельно, что чтобы как-то систематизировать и упорядочить всё это многообразие, чтобы облегчить жизнь рядовому пользователю, появилась W3C — организация, которая разрабатывает стандарты для web'а, включая стандарты доступности . Доступность (accessibility) — это не только для людей с ограниченными возможностями (слабовидящих, слабослышащих и проч.) как мы привикли воспринимать, а потому и забивать на неё. Для меня доступность — это правила вежливости при разработке сайтов и приложений, когда сайт помогает пользователю решить его проблему (залогиниться, заполнить форму, найти ка...

«Clean coder» Robert C. Martin

В 2024 году на наших фронтэндерских митосиках я открыла книжный клуб. Мы начали с обсуждения самой полезной разработчикам книги «Clean coder». И хотя наши митинги проходят каждую неделю, чтение книги — раз в две недели. Читаем по одной главе и обсуждаем: согласны с автором или нет, делимся своим опытом и болью, находим, что можно было бы поменять в себе, рефлексируем. К каждой главе я составляю краткий конспект — вопросы, которые можно было бы обсудить и над которыми можно самому подумать. Ниже представлен мой конспект по главам.     xiii. FOREWORD о чем история? кто из нас в трудностях закаляется (превращается в бриллиант)? почему эта история тут? чему она должна была нас научить или показать? xix. PREFACE о чем история о взорвавшемся Шаттле? кто виноват? xxiii. ACKNOWLEDGMENTS xxix. ABOUT THE AUTHOR xxxi. ON THE COVER почему автор на обложку поместил крабовидную туманность? PRE-REQUISITE INTRODUCTION почему автор так много описывает свою биографию и в особенности свои ош...