SQL parameter binding
Передача values окремо від SQL statement через placeholders і driver API. Це зберігає type handling і не складає query через string formatting.
Автомтизація баз даних та що з тим робити та що знати →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Entity, DAO, repository та ORM
Entity object відображає таблицю або persistence-модель, DAO інкапсулює низькорівневий доступ до даних, а repository формулює операції мовою домену, наприклад `findUserByEmail`. Межі цих назв різняться між ecosystem, тому важливіше розуміти відповідальність, а не механічно відтворювати всі шари. ORM перетворює об'єкти на relational data та генерує SQL. Він зменшує кількість ручних queries для стандартного CRUD, але не скасовує знання schema, indexes, transactions і joins. Для невеликого test-support helper достатньо вже наявного driver/repository; окремий ORM-шар лише для тестів часто створює дублювання production model.
Що перевіряти замість повторного тестування СУБД
Якщо застосунок використовує зрілий 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 у тесті.
Класи еквівалентності, boundary values та IDs
Таблиця розширюється через equivalence partitioning і boundary value analysis: валідний формат незареєстрованого email, відсутня локальна або domain-частина, пробіли, порожній пароль, занадто короткі чи довгі значення. Окремо LLM пропонує рядки, схожі на XSS і SQL injection payloads. Ці payloads є лише вхідними прикладами, а не доказом захищеності: security check повинен мати конкретний expected result і виконуватися в безпечному тестовому середовищі. Для кожної параметризованої ітерації задається `id`, щоб у pytest output і CI report було видно не номер набору, а зміст failed case. Запуск виявляє як помилки з Faker/API, так і server-side rate limit. Це корисний сигнал: параметризація збільшує кількість однотипних запитів, тому test data й темп запуску мають враховувати обмеження системи.
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.
ORM trade-offs і вибір першого automation seam
ORM є компромісом: прискорює типову розробку, але може генерувати неефективні queries або приховувати N+1, зайві joins і transaction behavior. Повертатися до ручного SQL слід за профілем і вимірюванням, а не через загальну недовіру до abstraction. У бажаній архітектурі backend виконує бізнес-перетворення, а frontend переважно відображає готовий contract. Якщо значна logic усе ж живе на frontend, це підсилює цінність UI/component automation. Коли продукт створюється з нуля й UI ще немає, логічно почати з API. Для наявного продукту без automation перший seam вибирають за ризиком і вартістю ручної регресії, а не за універсальним правилом «завжди UI» або «завжди backend».