--- course: ПиТПМ lecture: 7 title: "Лекция №7. Автоматизированное тестирование веб-интерфейсов (E2E) и управление асинхронными операциями." --- # Лекция №7. Автоматизированное тестирование веб-интерфейсов (E2E) и управление асинхронными операциями. ## §7.1. Эволюция E2E-инструментов: от Selenium к Playwright В первом семестре мы познакомились с **Selenium WebDriver** — классическим инструментом для автоматизации браузера. Мы научились: - Открывать браузер через new ChromeDriver(). - Находить элементы по ID, CSS, XPath. - Кликать, вводить текст, читать значения. - Использовать WebDriverWait для ожидания загрузки элементов. **Selenium** существует уже более 15 лет. Это проверенный, надежный инструмент, который используется в тысячах проектов по всему миру. Но у него есть проблемы, и вы с ними **уже столкнулись** (*или еще столкнетесь* 😏). Болевые точки **Selenium** (или почему индустрия ищет альтернативы) заключаются в проблемах, о которых мы сейчас поговорим. В 2020 году команда **Microsoft**, которая до этого разрабатывала инструмент **Puppeteer** (*для автоматизации Chrome*), решила создать **Playwright**. **Их цель была амбициозной** - сделать инструмент, который решает все перечисленные проблемы и работает одинаково хорошо **со всеми современными браузерами**. **Ключевая идея Playwright** - звучит так, что вместо того, чтобы управлять браузером через внешний драйвер, **Playwright** общается с браузером напрямую через **DevTools Protocol** — тот самый протокол, который используют инструменты разработчика `(F12)` в браузере. Вот как это выглядит в сравнении: | Характеристика | Selenium | Playwright | | --- | --- | --- | | **Способ общения** | Через внешний драйвер (WebDriver) | Напрямую через DevTools Protocol | | **Количество посредников** | Тест → Драйвер → Браузер | Тест → Браузер | | **Скорость** | Медленнее (лишний шаг) | Быстрее (прямое общение) | | **Сложность настройки** | Нужно устанавливать драйвер для каждого браузера | Достаточно установить браузеры через Playwright CLI | | **Работа с разными браузерами** | Разные реализации WebDriver | Единый API для Chrome, Firefox, Safari | | **Поддержка современных сайтов** | Хуже (особенно SPA) | Отличная (изначально создавался под SPA) | Давайте разберем архитектурное отличие **CDP** (*Chrome DevTools Protocol, то, что использует Playwright*) от **WebDriver** поподробнее, потому что это фундаментально меняет то, как работают тесты при работе с тестированием приложений. Для начала рассмотрим **Selenium WebDriver** (*старый подход*). Представьте, что вы хотите передать сообщение другу, но вы не можете говорить напрямую. Вы пишете письмо, отдаете его курьеру, курьер везет его вашему другу, друг читает, пишет ответ, отдает курьеру, курьер везет обратно. - Вы — ваш тест. - Курьер — WebDriver (chromedriver.exe). - Друг — браузер. **Каждое действие** (клик, ввод текста) — это отдельное письмо. Курьер может задержаться, потерять письмо или перепутать адресата. Теперь рассмотрим работу **Playwright** (новый подход). Представьте, что вы можете говорить напрямую по телефону с другом. Вы задаете вопрос, он отвечает мгновенно. Никаких посредников, никаких задержек. - Вы — ваш тест. - Телефонная связь — DevTools Protocol (CDP). - Друг — браузер. **Playwright** использует тот же протокол, что и **инструменты разработчика** (*DevTools*). Когда вы открываете `F12` в браузере, вы видите элементы, сетевые запросы, консоль — всё это работает через **CDP**. **Playwright** просто использует этот же канал для управления браузером. Что это дает на практике: `1.` **Скорость.** Команды выполняются быстрее, потому что нет лишнего посредника. `2.` **Надежность.** Меньше точек отказа — меньше шансов, что что-то пойдет не так. `3.` **Больше возможностей.** Playwright может перехватывать сетевые запросы, эмулировать мобильные устройства, подменять геолокацию — всё то, что Selenium делает с трудом или не делает вовсе. Важный нюанс Playwright управляет браузером снаружи, но имеет доступ к его внутреннему состоянию. Это позволяет ему: - Слушать сетевые запросы (перехватывать, подменять, проверять). - Внедрять JavaScript-код в контекст страницы. - Эмулировать разные устройства (iPhone, iPad, десктоп) без изменения кода. **Selenium** тоже умеет выполнять **JavaScript**, но делает это через **IJavaScriptExecutor**, что менее удобно и медленнее. Простая аналогия: - **Selenium** похож на управление роботом через пульт: вы нажимаете кнопку, он делает действие, но вы не знаете, что происходит внутри его «мозга». - **Playwright** — вы подключены к роботу через кабель и видите все его внутренние процессы. Вы можете не только давать команды, но и читать его мысли (состояние DOM, сетевые запросы, консоль). ## §7.2. Асинхронность как фундамент: async/await в тестах Когда в первом семестре мы писали тесты на **Selenium**, они выглядели следующим образом: csharp ```csharp [Fact] public void Login_ValidUser_ShowsDashboard() { var driver = new ChromeDriver(); driver.Navigate().GoToUrl("https://mysite.com/login"); driver.FindElement(By.Id("username")).SendKeys("admin"); driver.FindElement(By.Id("password")).SendKeys("12345"); driver.FindElement(By.Id("login-btn")).Click(); var welcome = driver.FindElement(By.CssSelector(".welcome")); Assert.True(welcome.Displayed); driver.Quit(); } ``` Это **синхронный код**. Каждая команда выполняется последовательно: `1.` Открыли страницу — ждем, пока загрузится. `2.` Нашли поле логина — нашли, идем дальше. `3.` Ввели текст — ввели, идем дальше. `4.` Нажали кнопку — нажали, идем дальше. **Код** выполняется **по шагам**, один за другим. Пока одна команда не завершится, следующая не начнется. Это просто и понятно. Мы все привыкли к такому стилю. Но у этого подхода **есть проблема**. Когда ваш **тест** отправляет команду **в браузер** (например, *«найти элемент»* или *«перейти по ссылке»*), происходит вот что: `1.` Ваш код отправляет команду. `2.` Команда проходит через сеть/процесс к браузеру. `3.` Браузер выполняет команду. `4.` Результат возвращается обратно. `5.` Ваш код получает результат и продолжает работу. Это операция **ввода-вывода** (*I/O*). Такие операции, в отличие от вычислений (например, сложение чисел), занимают **относительно много времени**. В чем же проблема **синхронного подхода**? Когда вы выполняете **синхронную операцию**, **поток выполнения** (*thread*) вашей программы блокируется. Он просто стоит и ждет, пока придет ответ от браузера. В это время он ничего не делает — просто тратит ресурсы впустую. ![](/images/lectures/pitpm/07/image-01.webp) Представьте, что вы ждете доставку пиццы. **Синхронный подход** — вы стоите у двери и смотрите в глазок, ничего не делая, пока не приедет курьер. **Playwright** с самого начала спроектирован как **асинхронный**. Это означает, что когда он отправляет команду в браузер, он не ждет в блокирующем режиме. Он говорит: *«Я отправил команду, а когда придет ответ — я тогда продолжу»*. В это время поток может делать другие полезные вещи (в контексте тестов — *готовить следующий запрос, обрабатывать другой* тест и т.д.). ![](/images/lectures/pitpm/07/image-02.webp) Давайте посмотрим на один и тот же тест, написанный в двух подходах. Что изменилось: `1.` Ключевое слово **async** в сигнатуре метода. `2.` Возвращаемый тип **Task** (или **Task** для методов с возвратом). `3.` Ключевое слово await перед каждым асинхронным вызовом. `4.` Все методы Playwright возвращают Task и требуют await. На первый взгляд — просто добавили **await** перед каждой строкой. Но за этим стоят серьезные архитектурные изменения. Когда вы пишете **await page.GotoAsync("...")**, происходит следующее: `1.` Метод **GotoAsync** возвращает **Task** — объект, который представляет собой «обещание» выполнить действие в будущем. `2.` Ключевое слово **await** говорит компилятору: *«Если задача еще не завершена, верни управление вызывающему коду. Когда задача завершится, продолжай выполнение с этой точки»*. `3.` Поток выполнения не блокируется. Он может обслуживать другие задачи (например, параллельные тесты). Простая аналогия – представьте, что вы заказываете еду в ресторане. - **Синхронный подход (Selenium):** Вы стоите у стойки и смотрите, как повар готовит. Вы не можете отойти, пока еда не будет готова. Вы блокируете очередь. - **Асинхронный подход (Playwright):** Вы делаете заказ, получаете номерок и садитесь за столик. Повар готовит, а вы в это время можете полистать меню, ответить на сообщения или просто отдохнуть. Когда еда готова, вам приносят. А как асинхронность борется с race conditions? Race condition (состояние гонки) — это ситуация, когда результат программы зависит от того, в каком порядке выполняются операции. В контексте E2E-тестов это часто выглядит так: `1.` Тест нажал кнопку. `2.` Сервер начал обрабатывать запрос. `3.` Тест пытается найти элемент, который появится после обработки запроса. `4.` Элемент еще не появился → тест падает. В **Selenium** вы решали эту проблему с помощью **WebDriverWait**: csharp ```csharp var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); var button = wait.Until( ExpectedConditions.ElementToBeClickable( By.Id("submit") ) ); ``` Вы вручную говорили: *«Подожди, пока кнопка станет кликабельной»*. Это работало, но требовало дисциплины. Забыли написать **WebDriverWait** — получили **flaky-тест**. В **Playwright** асинхронность тесно связана с механизмом автоматических ожиданий. Поскольку **Playwright** изначально асинхронный, он может *«подождать»* асинхронно, не блокируя поток, пока элемент не будет готов. csharp ```csharp // Playwright автоматически ждет, // пока элемент станет готов для действия // Не нужно писать явный WebDriverWait! await page.ClickAsync("#submit"); ``` Что происходит внутри: `1.` **Playwright** получает команду *«кликнуть по #submit»*. `2.` Он асинхронно проверяет: *«Этот элемент видим? Стабилен? Не перекрыт другим элементом?»*. `3.` Если нет — он ждет (не блокируя поток) и проверяет снова. `4.` Как только элемент становится готов — выполняет клик. `5.` Если элемент не появился за таймаут — бросает понятную ошибку. В **Selenium** вы ждали вручную. В **Playwright** ожидание встроено в каждый метод. Что это дает на практике? Меньше кода для стабильности: | Характеристика | Selenium | Playwright | | --- | --- | --- | | **Ожидания элементов** | Нужно явно писать WebDriverWait для каждого действия | Ожидания встроены в методы, не нужно писать дополнительный код | | **Риск flaky-тестов** | Если забыли WebDriverWait — тест может стать flaky | Flaky-тесты встречаются реже, потому что ожидания работают автоматически | | **Настройка таймаутов** | Сложно настроить правильное время ожидания | Таймаут настраивается глобально для всего теста | Поскольку **Playwright** не блокирует поток во время ожидания, вы можете запускать несколько тестов параллельно, и они будут выполняться быстрее. Правило для запоминания В Playwright каждое действие с браузером — асинхронное. Всегда используйте **await** перед вызовом методов **Playwright**. **Если забыли — тест упадет** ### §7.3. «Умные» ожидания: уход от Thread.Sleep и WebDriverWait В **лекции №4** первого семестра мы подробно разбирали **антипаттерн «Спящий тест»**: csharp ```csharp // ❌ ПЛОХО: гадаем, сколько времени нужно ждать Thread.Sleep(3000); // Ждем 3 секунды "на всякий случай" driver.FindElement(By.Id("submit")).Click(); ``` И даже правильный вариант с **WebDriverWait** выглядел громоздко: csharp ```csharp // ⚠️ ЛУЧШЕ, но все равно приходится писать лишний код var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); var button = wait.Until( ExpectedConditions.ElementToBeClickable( By.Id("submit") ) ); button.Click(); ``` Проблема **Selenium** в том, что он не знает, готов ли элемент к взаимодействию. Он просто ищет элемент в **DOM** (*структуре страницы*) и пытается с ним работать. А если элемент есть в **DOM**, но еще не отрисовался или перекрыт другим блоком — **Selenium** падает. Вы, как **разработчик теста**, вынуждены вручную объяснять **Selenium**: *«Подожди, пока кнопка станет кликабельной»*. И если вы забыли это сделать — тест становится **нестабильным** (*flaky*). В **Playwright** подход кардинально другой. Перед тем как выполнить любое действие (клик, ввод текста, наведение), **Playwright** автоматически **выполняет серию проверок**. Это называется **Actionability Checks** (проверки готовности к действию). Что именно проверяет Playwright перед кликом или вводом текста: | Проверка | Что это значит | Пример проблемы | | --- | --- | --- | | **Видим ли элемент?** | Элемент не скрыт CSS-свойством display: none или visibility: hidden | Элемент есть в коде, но еще не появился на экране | | **Стабилен ли элемент?** | Элемент не двигается по странице (например, не анимируется) | Анимация появления, слайдер, бегущая строка | | **Не перекрыт ли элемент?** | Никакой другой элемент не находится поверх него | Всплывающая реклама, модальное окно, загрузочный спиннер | | **Не отключен ли элемент?** | У элемента нет атрибута disabled | Кнопка "Отправить" заблокирована, пока не заполнены все поля | Что это значит для вас, как для разработчика тестов? Вы просто пишете: csharp ```csharp // Всего одна строка. Playwright сам сделает все проверки! await page.ClickAsync("#submit"); ``` **Playwright** не просто кликает. Он: `1.` Ждет, пока элемент появится в DOM. `2.` Проверяет, что он видим. `3.` Проверяет, что он стабилен (не двигается). `4.` Проверяет, что он не перекрыт. `5.` Проверяет, что он активен. `6.` И только после этого выполняет клик. Если элемент **не готов** в течение таймаута (*по умолчанию 30 секунд*), **Playwright** выбросит понятную ошибку с указанием, какая именно проверка не прошла. Простая аналогия: - **Selenium** — это как человек, который пытается пожать руку, даже не посмотрев, есть ли перед ним человек. Он просто машет рукой в пустоту и удивляется, почему никто не ответил. - **Playwright** — это как человек, который сначала смотрит на собеседника, убеждается, что он смотрит в ответ, протягивает руку, ждет ответного рукопожатия и только потом здоровается. Вторая гениальная фишка **Playwright** — это **Web-First Assertions** (*утверждения, ориентированные на веб*). В **Selenium** вы писали так: csharp ```csharp var message = driver.FindElement(By.Id("success")); // Если сообщение еще не появилось — тест упадет Assert.True(message.Displayed); ``` Вы делали проверку один раз. Если сообщение появлялось через 2 секунды, а вы проверили через 1 секунду — тест падал. Выход — снова использовать **WebDriverWait**: csharp ```csharp var wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); var message = wait.Until(d => d.FindElement(By.Id("success"))); Assert.True(message.Displayed); ``` В **Playwright** проверки работают по-другому. Они автоматически **повторяются** (*retry*), пока условие не выполнится или не истечет таймаут. csharp ```csharp // Playwright будет проверять это условие снова и снова // пока сообщение не появится или не пройдет 5 секунд await Expect(page.Locator("#success")).ToBeVisibleAsync(); ``` Что происходит внутри: `1.` **Playwright** проверяет, видим ли элемент. `2.` Если нет — он ждет короткое время (например, 100 мс). `3.` Проверяет снова. `4.` И так до тех пор, пока элемент не появится или не истечет таймаут. Это называется **автоматическим ретраем** (*auto-retry*). Именно это делает тесты на **Playwrigh**t стабильными без лишнего кода. Давайте посмотрим на один и тот же сценарий (клик по кнопке и проверка появления сообщения) в двух подходах. Вот полный пример теста на **Playwright** для **.NET**, в котором нет ни одного **Thread.Sleep** или явного **WebDriverWait**: csharp ```csharp [Fact] public async Task UserCanAddProductToCart() { // 1. Настраиваем Playwright using var playwright = await Playwright.CreateAsync(); await using var browser = await playwright.Chromium.LaunchAsync(); var page = await browser.NewPageAsync(); // 2. Переходим на сайт (ждет загрузки автоматически) await page.GotoAsync("https://myshop.com"); // 3. Ищем товар (ждет, пока появится поле поиска) await page.FillAsync("#search-input", "iPhone 15"); await page.ClickAsync("#search-button"); // 4. Ждем, пока появится список товаров (автоматически) // Кликаем по кнопке "В корзину" у первого товара await page.ClickAsync(".product-card:first-child .add-to-cart"); // 5. Переходим в корзину (ждет, пока кнопка станет кликабельной) await page.ClickAsync("#cart-icon"); // 6. Проверяем, что товар в корзине (автоматический retry) await Expect(page.Locator(".cart-item")) .ToHaveTextAsync("iPhone 15"); // 7. Оформляем заказ (ждет, пока кнопка станет активной) await page.ClickAsync("#checkout-button"); // 8. Проверяем, что заказ оформлен (автоматический retry) await Expect(page.Locator(".order-confirmation")) .ToBeVisibleAsync(); } ``` Где здесь ожидания? - **Нет Thread.Sleep** — мы не гадаем, сколько времени нужно ждать. - **Нет WebDriverWait** — не нужно писать сложные условия. - **Нет ручных ожиданий** — Playwright сам решает, когда элемент готов. Если страница загрузилась за 0.5 секунды — тест продолжается сразу. Если за 5 секунд — **Playwright** подождет 5 секунд. Если за 31 секунду — тест упадет с ошибкой, и вы точно будете знать, что проблема в производительности, а не в тесте. Почему это работает. Самое основное, это встроенные таймауты. У **Playwright** есть **разумные таймауты** по умолчанию: - **Таймаут для действий (ClickAsync, FillAsync, GotoAsync)** — 30 секунд. - **Таймаут для проверок (Expect)** — 5 секунд. Вы можете изменить их глобально для всех тестов или локально для конкретного действия: csharp ```csharp // Увеличиваем таймаут для конкретной проверки await Expect(page.Locator(".slow-element")) .ToBeVisibleAsync(new() { Timeout = 15000 }); ``` Но в большинстве случаев стандартные настройки работают отлично. А что делать, если элемент все равно не находится? Иногда **Playwright** не может найти элемент, потому что он появляется только после выполнения **JavaScript-кода** на странице. В этом случае вы можете использовать дополнительные методы ожидания: csharp ```csharp // Ждем, пока элемент появится в DOM await page.WaitForSelectorAsync("#dynamic-element"); // Или ждем, пока исчезнет загрузочный спиннер await page.WaitForSelectorAsync(".loader", new() { State = WaitForSelectorState.Hidden }); ``` Но даже в этом случае вы не пишете **Thread.Sleep** — вы ждете конкретное условие, а не произвольное время. В заключение, хочется подытожить ключевыми отличиями двух подходов, а именно **Selenium** и **Playwright**. | Что делаем | Selenium | Playwright | | --- | --- | --- | | **Ожидание кликабельности** | Пишем WebDriverWait + ExpectedConditions | Встроено в ClickAsync() | | **Ожидание появления элемента** | Пишем WebDriverWait + FindElement | Встроено в Expect().ToBeVisibleAsync() | | **Количество строк кода для ожиданий** | 3-4 строки на каждое действие | 0 строк — всё встроено | | **Риск забыть ожидание** | Высокий (тест станет flaky) | Низкий (ожидания всегда работают) | ## §7.4. Современный Page Object Model для Playwright: Locators и Page Factory В лекции №4 первого семестра мы разбирали **Page Object Model** для **Selenium**. Класс страницы выглядел примерно так: csharp ```csharp public class LoginPage { private readonly IWebDriver _driver; // Локаторы через By.Id, By.XPath, By.CssSelector private By UserNameField => By.Id("username"); private By PasswordField => By.Id("password"); private By LoginButton => By.XPath("//button[text()='Войти']"); public LoginPage(IWebDriver driver) { _driver = driver; } public HomePage LoginAs(string username, string password) { _driver.FindElement(UserNameField).SendKeys(username); _driver.FindElement(PasswordField).SendKeys(password); _driver.FindElement(LoginButton).Click(); return new HomePage(_driver); } } ``` Проблемы этого подхода: `1.` **Локаторы хрупкие.** Если дизайнер поменял структуру `HTML` — `XPath` ломается. `2.` **Сложно читать.** `By.XPath("//div[3]/form/button[1]")` — это магия, а не инструкция. `3.` **Найдет что угодно.** `XPat`h может найти неправильный элемент, если структура страницы изменилась. `4.` **Нет приоритетов.** **Selenium** не подсказывает, какой локатор лучше использовать. В **Playwright** полностью отказались от старого подхода с `By.Id`, `By.XPath` и `FindElement`. Вместо этого используется **Locators API** — новый, более умный способ поиска элементов. **Locator** — это объект, который представляет собой инструкцию по поиску элемента на странице. Но в отличие от **Selenium**, **Locator** в **Playwright** — это ленивый объект. Он не ищет элемент сразу, а только запоминает, как его найти. Реальный поиск происходит только в момент действия (клик, ввод текста). csharp ```csharp // Locator — это просто инструкция, элемент еще не найден var submitButton = page.Locator("#submit"); // Только здесь Playwright реально ищет элемент // и проверяет его готовность await submitButton.ClickAsync(); ``` Почему это круто: `1.` **Автоматические ожидания.** Locator сам ждет, пока элемент появится и станет готов к действию. `2.` **Переиспользование.** Один Locator можно использовать в разных методах. `3.` **Читаемость.** Locator строится как цепочка понятных методов. В **Playwright** есть четкая иерархия того, как искать элементы. Разработчики **Playwright** рекомендуют использовать локаторы в следующем порядке приоритета: **1. GetByRole (САМЫЙ ПРИОРИТЕТНЫЙ)** Ищет элемент по его роли **в доступности** (*ARIA*). Это самый надежный способ, потому что роли редко меняются, даже если дизайн перерисовывают. csharp ```csharp // Найти кнопку по роли "button" и тексту "Войти" var loginButton = page.GetByRole(AriaRole.Button, new() { Name = "Войти" }); // Найти поле ввода по роли "textbox" var usernameField = page.GetByRole(AriaRole.Textbox, new() { Name = "Имя пользователя" }); ``` Когда использовать Всегда, когда элемент имеет правильную ARIA-роль. Это делает тесты устойчивыми к изменениям вёрстки. **2. GetByText** Ищет элемент по тексту, который видит пользователь. csharp ```csharp // Найти кнопку с текстом "Добавить в корзину" var addToCartButton = page.GetByText("Добавить в корзину"); // Найти заголовок с текстом "Добро пожаловать" var welcomeHeader = page.GetByText("Добро пожаловать"); ``` Когда использовать Для ссылок, кнопок, заголовков — всего, что имеет понятный текстовый контент. **3. GetByLabel** Ищет элемент по связанному с ним тексту `label` (для полей ввода). csharp ```csharp // Найти поле ввода, рядом с которым есть label "Email" var emailField = page.GetByLabel("Email"); // Найти поле ввода, рядом с которым есть label "Пароль" var passwordField = page.GetByLabel("Пароль"); ``` Когда использовать Для полей ввода, которые имеют HTML-тег `