Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Візьміть один реальний web або API automation scope.
Створіть лише folders, які мають хоча б один поточний consumer.
Запишіть measurable condition для винесення database, messaging або другого domain на окремий рівень.
Мінімальне tree representation і три explicit upgrade conditions.
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
Один і той самий service може бути producer для одного виклику і consumer для іншого. Тому response, яку отримує frontend, може залежати від кількох внутрішніх викликів. Чиста теоретична модель не завжди збігається з production: дедлайни змушують команду накопичувати technical debt і порушувати ідеальні межі. Тестувальник має досліджувати фактичні зв’язки, а не покладатися лише на назви сервісів.
Сервіс orders може публікувати подію в Kafka або інший broker, а consumer — зчитувати її і оновлювати status. Асинхронна queue допомагає приймати spikes швидше, ніж downstream встигає повністю опрацювати кожен order. Це не усуває навантаження, а змінює його форму і час. Для тесів з’являються окремі питання: чи опубліковано подію, чи вона була опрацьована, що відбувається з retries, duplicates і відкладеною consistency.
Запит від browser, mobile або IoT device може пройти DNS, load balancer/API gateway, потім один або кілька services. Java backend у прикладі будується на Spring/Spring Boot, читає database або публікує asynchronous event. Kafka, RabbitMQ та інші brokers допомагають розв’язати producer і consumer у часі. Для тестів це означає, що request success не завжди доводить completed business outcome: потрібно перевіряти event publication, processing, retries і final state.
Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.
Перевірка одного HTTP response не покриває asynchronous processing. Для Kafka/RabbitMQ flow окремо перевіряють publication, consumer processing, state change і downstream integrations. Component test може ізолювати service з mocks/stubs, а environment test — перевірити real wiring. Ні один рівень не замінює інший; assertion design має відповідати failure boundary цього тесту.
Generator може створити `assertThat(pet).hasName(...)`, але import conflicts і plugin age можуть звести користь нанівець. Сучасний AssertJ already має rich extracting/recursive/custom assertion APIs, тому generation варта лише для real repeated domain vocabulary. API-first підхід робить specification upstream input для backend і clients. Jackson deserialization вже перевіряє shape/types, але не доводить business semantics. Окрема contract-testing infrastructure потрібна, коли spec/code generation не закривають real producer–consumer risk.