Прихована складність бекенд-тестування

[Дивитися з 00:00](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=0s). Запрошення учасника здається простою функцією, доки не врахувати репутацію домену, правила SMTP-провайдера, корпоративні spam-фільтри, реєстрацію застосунку, rate limits і вартість кожного листа. Окремо треба перевіряти email templates: наявність потрібного шаблону, параметризацію тексту, обов'язкові змінні та поведінку одразу після створення, коли сторонній сервіс ще може повертати закешований стан. Тест «створили template — відразу надіслали invite» може бути нестабільним не через код продукту, а через eventual consistency інтеграції.

[Дивитися з 06:10](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=370s). У реальній архітектурі browser звертається до API gateway, той перевіряє authentication та authorization, передає запит backend-сервісу, а backend отримує шаблон або ініціює відправлення через інший сервіс. Invite token має бути згенерований правильним компонентом, переданий без зміни й мати визначений TTL. Якщо контракт нечіткий, один сервіс може додати зайвий або захардкоджений token, після чого формально валідний request завершується невалідним invite. Перевірка лише зовнішньої специфікації endpoint не знаходить помилку в розподілі відповідальності між сервісами.

[Дивитися з 11:05](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=665s). SMS-провайдер на кшталт Twilio приховує різні carrier contracts, billing і правила блокування. Успішний тест на одному українському префіксі не доводить доставлення через Vodafone чи оператора іншої країни: окремі ranges можуть бути заблоковані через fraud. Атака на authorization endpoint може витратити платний SMS-бюджет або спричинити блокування application, тому потрібні rate limits на правильному рівні. Водночас надто грубе обмеження за IP заблокує весь офіс або тестове середовище. OTP із TTL одна хвилина функціонально непридатний у країні, де SMS приходить за дві хвилини. Для автоматизації часто потрібні test numbers або контрольований bypass, але вони не замінюють окремої end-to-end перевірки реального каналу.

[Дивитися з 17:28](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1048s). Один Get Products може агрегувати базову інформацію, зображення з object storage, персональну або гуртову ціну, VAT, промо-правила, related products і дані зовнішнього податкового провайдера. Розрахунок залежить від типу покупця, країни, собівартості та локального законодавства. Державні реєстри чи їхні агрегатори можуть бути платними, повільними або недоступними, тому відповіді кешуються. Через це тест має визначити джерело кожного поля, правила fallback, паралельні залежності, cache hit/miss та допустиму застарілість даних, а не лише порівняти один JSON із очікуваним.

[Дивитися з 22:13](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1333s). Backend testing охоплює не тільки response body, а й правила зберігання, видалення та повідомлення користувача про персональні дані. Навіть архітектура без окремих controllers — наприклад, REST-інтерфейс поверх PostgreSQL через PostgREST — не скасовує перевірок access control, фільтрації та дозволених операцій. Прямі CRUD-запити можуть бути простими синтаксично, але безпека й видимість rows усе одно залежать від правил у шарі даних.

[Дивитися з 24:35](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=1475s). Простим можна вважати потік без зовнішніх інтеграцій і складних доменних правил, де запит напряму читає дозволені поля. Але навіть там можуть з'явитися GraphQL-подібні запити, складна authorization-фільтрація або performance-проблеми в database. Головний висновок: тестувальник має намалювати реальний dependency flow, з'ясувати, де виконуються authentication, authorization, billing, caching і error handling, а вже потім обирати рівні тестування та automation. Простота UI чи OpenAPI-контракту не є доказом простоти системи.