Пошук · Мануфактура

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

Java · Сесії: AMA та PMP · 0:00–1:27

Інтеграційні та компонентні тести в сучасних системах

Сучасні системи часто збираються на зрілих фреймворках на кшталт Spring, Django, Angular або Next.js. Через це багато базової поведінки вже реалізовано й перевірено фреймворком, тож команді не обов’язково компенсувати все великою кількістю власних unit-тестів. Значну цінність дають інтеграційні та компонентні перевірки. У наведеному розмежуванні інтеграційний тест перевіряє функцію, клас або сервіс із замоканими зовнішніми залежностями, включно з базою даних. Компонентний тест піднімає сервіс разом із реальною тестовою БД, але ізолює сторонні системи. Отже, компонентний тест перевіряє більший реальний зріз застосунку.

Піраміда тестування, чому не API спочатку та як жити з упровадженням ШІ →

Java · Сесії: AMA та PMP · 3:06–3:20

Від піраміди тестування до test trophy

Показується класична тестова піраміда й одразу згадується альтернативна модель — test trophy. Детальне пояснення сучасного розподілу тестів продовжується в наступному відео.

Як проходити курс та його логіка →

Java · Сесії: AMA та PMP · 14:30–17:00

Test trophy і правильний розподіл перевірок

У відео test trophy протиставляється механічній testing pyramid: в основі quality gates лежать static analysis і security checks, далі — швидкі unit tests, ширший шар integration tests і невелика кількість end-to-end scenarios. Ідея — інвестувати в той рівень, де система має найбільший ризик і де перевірка дає швидкий надійний сигнал. Важливе уточнення: не слід зменшувати unit coverage лише тому, що продукт використовує Spring, Django або готову database. Не потрібно тестувати код framework; потрібно unit-тестувати власну чисту domain logic, а integration tests залишити для mappings, transactions, SQL, serialization та зовнішніх contracts.

Автомтизація баз даних та що з тим робити та що знати →

Java · Сесії: AMA та PMP · 47:39–54:14

Testing trophy, статичний аналіз і мовні layout conventions

Структура каталогів не визначає правильний рівень coverage. Для сучасних frameworks часто корисніше мислити test trophy або testing landscape: поєднувати static analysis, component/integration tests і лише потрібні end-to-end tests відповідно до ризику конкретної частини системи. У Java типовий layout має `src/main` і `src/test` із packages; Python та TypeScript часто відділяють application/support code від tests простіше. Naming і package layout треба брати з conventions мови та поточного repository, а не переносити механічно з іншого stack.

Неймінг та структура automation-проєкту →

Запитати в чаті про «test-trophy» →