Python мануфактураJavaDesign Patterns для автоматизаторів

Java · Сесії: AMA та PMP · 18:42–22:55

Strict schema та negative behavior

Для критичних контрактів рекомендовано схилятися до strict validation: обов’язкове поле має бути присутнім і мати визначений тип. Щоб така перевірка була змістовною, test fixture треба створювати з повним набором даних, а не випадково залишати половину полів порожніми. Генерація готових моделей прискорює роботу, але ручний red/green шлях іноді знаходить backend defects саме під час поступового заповнення й перевірки полів. Повністю «ідеальна» згенерована модель може приховати досвід негативних сценаріїв, хоча саме неочікувані дані часто відкривають проблеми.

Міграція бази даних і тестування даних →

Java · Advanced: API-автоматизація · 20:00–25:00

HTTP methods і status codes як частина contract

`GET`, `POST`, `PUT`, `DELETE` мають різні очікувані effects. `200 OK`, `201 Created`, `202 Accepted`, `204 No Content`, client errors `4xx` і server errors `5xx` не слід згортати в одне «працює/не працює». Особлива увага приділяється `PUT`, де behavior для nonexistent resource залежить від contract. Автотест має кодувати домовленість конкретного API, а не універсально вважати один code правильним для всіх APIs.

Теоретичний вступ до вебсервісів →

Java · Advanced: API-автоматизація · 1:10:00–1:30:00

Resource controllers і negative responses

Коли один endpoint method потрібен кільком тесам, він переходить у resource controller/service. Межа class залежить від real API: окремий service на resource або кілька related resources в одном service client. Для negative tests controller краще повертати raw `Response`, щоб test явно перевірив status, headers і error body. Примусова deserialization success DTO для `4xx/5xx` сховає реальний contract.

POJO, Jackson і контролери →
Запитати в чаті про «negative-testing» →