Browser-test contract
Playwright рекомендує user-visible behavior, isolation, контроль тестових даних і відмову від прямої залежності від неконтрольованих third-party systems.
Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
NIST AI 600-1: Generative AI Profile
Дає primary-source risk controls для privacy, sensitive data, governance та third-party GAI use.
Як працювати на спокійному проєкті та з нав’язаними оцінками → Першоджерело ↗SAST, DAST і SCA
SAST шукає weaknesses у code, DAST перевіряє running application ззовні, а SCA зіставляє third-party components із відомими vulnerabilities. Це доповнювальні techniques, а не взаємозамінні назви одного scanner-а.
Перехід у пентестинг: що важливо →Локальний запуск і кілька середовищ
Один репозиторій запускається локально й у CI проти dev, preprod або інших середовищ. Сервіси можуть залежати від баз даних і зовнішніх third-party систем, інколи спільних для кількох середовищ. Локальний ноутбук часто отримує доступ до закритої мережі лише через VPN, тому той самий маршрут не можна автоматично перенести на hosted runner.
Codegen і trace як контрольована відправна точка
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
Gateway, load balancer і спільні залежності
Публічніше середовище може бути захищене authentication gateway, rate limits і load balancer замість VPN. Gateway приймає зовнішній трафік і маршрутизує його до потрібного сервісу; load balancer розподіляє запити між копіями. Під час проєктування тестів треба знати, які середовища ділять third-party інстанс і де саме застосовуються мережеві та частотні обмеження.
Hexagonal architecture як структура коду
Гексагональна архітектура пояснює, як декомпозувати сервіс за відповідальністю та способом взаємодії з довкіллям. Окремі adapters працюють з REST, WebSocket, email, SMS, database, message queue і third-party services, не змішуючи все в одному класі. Для тестувальника такий поділ дає карту ports і failure seams: можна окремо перевірити domain behavior, adapter contract і повний ланцюжок інтеграції.
Де solo/fullstack підхід починає ламатися
[Дивитися з 12:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=720s). Зі зростанням system з’являються multiple services, authorization for external clients, складні database relations і third-party calls. Generated implementation може непомітно створити N+1 queries, дублювати requests або багато разів викликати зовнішній provider заради одного UI response. Локально feature працює, але її operational cost і latency стають неприйнятними на реальному traffic.
Third-party, SSO, OTP і тестові провайдери
Створення та вхід можуть залежати від payment provider, державного сервісу, SSO, email/SMS OTP або MFA. Зовнішній провайдер не завжди має повноцінний sandbox; навіть коли він є, можливості та тарифи тестового режиму відрізняються. Для тестового середовища потрібен офіційний test tenant/API key, тестові картки або керований спосіб отримати OTP. Інший варіант — окрема test-only форма з login/password, увімкнена серверною конфігурацією лише поза production. Це дає автоматизації стабільний шов, але не замінює окремі acceptance-тести справжньої інтеграції з провайдером.
Proxy-debugging і некоректні backend responses
Proxyman, Charles або Fiddler дозволяють перехопити request, змінити його, затримати відповідь чи підмінити response. Так перевіряються offline mode, повільний інтернет, перемикання Wi-Fi/LTE, timeouts, `4xx`/`5xx` і неочікувані backend payloads. Особливу увагу приділено `null`, відсутнім полям і зміні типів: замість масиву може прийти `null`, число може мати інший тип, а object mapping — завершитися crash. Mobile client має коректно переживати serialization/deserialization помилки й недоступність third-party services.
Third-party SDK, SMS-витрати й testability
Несумісні версії SDK або gRPC-залежностей можуть спричинити crash лише під час відкриття конкретного екрана. Окремо розглядається SMS/OTP flow: повторні запити створюють реальні витрати й можуть стати resource-exhaustion атакою, тому потрібні rate limits, bot protection і безпечний test bypass. Dev build може передавати спеціальний header або environment configuration, щоб не надсилати реальне SMS і не викликати reCAPTCHA. Це приклад testability — архітектурної властивості, яку тестувальник має обговорювати з командою до автоматизації.