Чому саме Cypress?
Є безліч фреймворків для тестів у JS (Jest, Mocha, Playwright), але для end-to-end тестів сьогодні найбільше використовують Cypress. Це інструмент, який дозволяє симулювати поведінку реального користувача у браузері.

Що робить Cypress зручним?
🖥️ Тести у браузері
Ви бачите на власні очі, як відкривається сторінка, заповнюється форма й клікаються кнопки. Це схоже на «живу» перевірку.

🎛️ Візуальний інтерфейс
Не просто консоль, а цілий UI: можна поставити паузу, прогорнути виконання крок за кроком і подивитись, де саме тест впав.

📸 Скріншоти та відео
Якщо тест ламається на CI, Cypress робить знімок екрану або відеозапис. Зручно для відлагодження.

⚡ Гнучкість
Однаково добре працює з React, Vue, Angular та навіть з бекендом, якщо треба тестувати API.

⏳ Автоматичне очікування
Не потрібно писати

sleep()

– Cypress сам чекає, поки елемент з’явиться у DOM.

Мінімальний приклад

// cypress/e2e/login.cy.js
describe('Login flow', () => {
  it('користувач може увійти', () => {
    cy.visit('/login')
    cy.get('input[name=email]').type('[email protected]')
    cy.get('input[name=password]').type('Password1!')
    cy.contains('Sign in').click()
    cy.contains('Welcome').should('be.visible')
  })
})

🔍 У цьому прикладі Cypress «грає роль» користувача:
- відкриває сторінку

/login

- вводить email і пароль,
- клікає кнопку «Sign in»,
- перевіряє, що на екрані з’явився текст «Welcome».

✅ Можна сказати, що Cypress – це ваш інтерактивний робот-тестувальник, який клікає замість вас, і робить це без втоми та помилок.

💬 А ви вже пробували Cypress у своїх проєктах, чи поки що користуєтесь тільки unit-тестами на Jest/Mocha?

✨ Гарних вихідних, відпочиньте та набирайтеся сил!

#codica_advice

TikTok | Instagram | Telegram

Доброго ранку, друзі! Смакуйте каву, повторіть чарівні слова з картинки 3 рази, можливо щось зміниться 😄

Продуктивного усім робочого тижня!

#codica_humor

TikTok | Instagram | Telegram

Як відповідати на питання на співбесіді?

#codica_interviews

❌ Давати швидку відповідь без підготовки – погана ідея.
✅ Пройти ключові питання заздалегідь і зрозуміти, як пояснювати – правильний підхід.

1️⃣ Які бувають вимоги до тестування?
📌 Очікувана відповідь:
• Функціональні (що має робити система)
• Нефункціональні (швидкодія, безпека, зручність, сумісність тощо)
• Бізнес-вимоги (чого хоче досягти замовник)
• Технічні обмеження (платформи, інтеграції, середовище)

2️⃣ Що робити, якщо вимоги відсутні?
📌 Очікувана відповідь:
• Переглянути будь-яку доступну документацію (якщо є хоч щось).
• Обговорити з бізнесом або командою очікувану поведінку.
• Орієнтуватися на аналогічні системи або схожий функціонал.
• Прописати власні припущення та погодити їх із командою/PO.
• Виконати exploratory testing, щоб знайти очевидні баги навіть без формальних вимог.

3️⃣ Який тип/вид клас тестування має сенс автоматизувати?
📌 Очікувана відповідь:
• Регресійні – повторювані сценарії після кожного релізу.
• Smoke-тести – перевірка, що система взагалі стартує.
• Data-driven – один сценарій із різними наборами даних.
• API-тести – швидкі, стабільні, критично важливі для інтеграцій.
• Performance (частково) – коли важливо перевірити навантаження або стабільність.

❌ Що НЕ завжди має сенс автоматизувати:
– Одноразові або рідкісні сценарії.
– Тести з часто змінним UI.
– Дослідницькі (exploratory) тести, де важлива гнучкість.

🙌 Друзі, бажаємо вам легких та вдалих співбесід і гарного вечора!
До зустрічі завтра 🚀

TikTok | Instagram | Telegram