QAПідрозділ
Автоматизація
Три браузерні інструменти, кожен пояснений через один архітектурний факт, з якого випливає все інше. Playwright керує браузером ззовні через одне зʼєднання; Cypress працює всередині вкладки разом із вашим застосунком; Selenium — це опублікований стандарт W3C із прикріпленими бібліотеками. Прочитайте архітектуру — і списки можливостей пояснять себе самі, включно з тим, чого кожен інструмент не може. Що взагалі належить браузерному тесту — на сторінці E2E, а не тут.
Що всередині
Усі сторінки цієї групи — і про що кожна з них.
- PlaywrightКерування поза процесом через одне зʼєднання: автоочікування, траси й ізоляція контекстів випливають саме з цього.АвтоочікуванняКонтексти
- CypressЖиття у вкладці: черга команд, повторні перевірки, подорож у часі — і стеля, яку накладає те саме рішення.ПовториОдна вкладка
- SeleniumW3C WebDriver як стандарт, тож обидва кінці змінні, — плюс Grid, пастка очікувань і де він досі виграє.W3CGrid
З чого почати
- Починаєте новий набірPlaywright. Це розумний вибір за замовчуванням у 2026 році, і його сторінка одразу називає застереження.
- Тести належать фронтенд-розробникамCypress, надто розділ про компонентне тестування: саме там основна цінність для фронтенд-команди.
- Багато мов або справжні браузериSelenium. Свобода мов і матриця справжніх браузерів на відкритому стандарті — цього більше ніхто не дає.
Інше в цьому розділі
- QAЗабезпечення якості (QA) — це практика вирішувати, що перевіряти, запускати ці перевірки достатньо часто, щоб вони мали сенс, і розуміти, що змінюється, коли те, що тестують, перестає давати ту саму відповідь двічі. У розділі 9 тем у трьох групах: види тестування, які всі памʼятають наполовину; автоматизація на Playwright, Cypress і Selenium; і тестування продуктів на мовних моделях, де твердження стає оцінкою, а не рівністю.
- Види тестуванняТри види тестів, які кладуть в один список і які не є порівнюваними. Smoke — це ворота: він вирішує, чи вартий білд чийогось часу. Регресія — це памʼять: вона памʼятає, що вже одного разу зламалося. Наскрізний — це рівень: єдине місце, де можна довести, що зібрана система працює. Перші два є причинами запускати тести й можуть бути написані на будь-якому рівні, — і саме цю відмінність пропускає більшість відповідей на співбесідах.
- DevOpsЯк довести зміну з машини розробника до працюючої системи — повторювано й без церемоній. Три теми, що складаються одна на одну: пайплайн, що вирішує, чи зміна безпечна; формат образу, який робить «у мене працює» перевірюваним твердженням; і планувальник, що тримає результат запущеним. Кожна сторінка про механізм, а не про синтаксис конфігурації інструмента, — саме механізм і переноситься при зміні інструментів.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.