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

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

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

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

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

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

Java · Сесії: AMA та PMP · 0:00–6:10

Email-запрошення: доставлення, шаблони й eventual consistency

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

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

Java · Сесії: AMA та PMP · 6:30–10:30

Що перевіряти замість повторного тестування СУБД

Якщо застосунок використовує зрілий framework і ORM, automation suite не має доводити, що framework у принципі вміє зберігати рядок. Цінність дають перевірки власної конфігурації: migrations, column types, precision, foreign keys, transaction boundaries, custom queries і mapping між database та API. Часто API або UI test уже опосередковано проходить database integration. Окремий DB assertion потрібен, коли зовнішня відповідь не доводить важливу властивість persistence — наприклад audit record, точність money value або асинхронний статус. Для dashboards, statistics і Big Data ключовою є не сама таблиця, а правильність агрегації: joins, filters, rounding, time zones і перетворення backend. Тут доцільно порівнювати результат із контрольованим dataset або незалежно обчисленим oracle, а не дублювати той самий SQL у тесті.

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

Запитати в чаті про «integration-testing» →