AI-система автоматичної генерації інтеграційних тестів

AI-автогенерація інтеграційних тестів

Інтеграційні тести часто стають вузьким місцем у CI пайплайні: вони або відсутні, або падають через крихкі фікстури. Ми вирішуємо це за допомогою AI-генерації, яка аналізує архітектуру сервісів, схему бази даних та OpenAPI-специфікації. Результат — готові pytest-тести, які знаходять реальні баги, а не плодять хибні спрацьовування. Час регресії скорочується до 4 годин замість трьох днів, а витрати на тестування — до 40%.

Які проблеми вирішує AI-генерація тестів?

Ручне написання інтеграційних тестів забирає 2–3 дні у QA-інженера на кожен реліз. При цьому 80% коду тестів шаблонні: однотипні CRUD-перевірки, виклики API з різними параметрами, підняття тестових даних. AI-генератор бере на себе рутину, звільняючи команду для аналізу складних кейсів.

Неповне покриття — часта біль мікросервісних архітектур. Вручну легко пропустити ланцюжок "замовлення → оплата → сповіщення → склад". AI перебирає всі комбінації контрактів і генерує тести для кожного інтеграційного шляху, включаючи граничні випадки. Покриття зростає в 4–6 разів порівняно з ручним підходом.

Крихкі тести — фікстури, зав'язані на бойові дані, ламаються при кожній зміні схеми. Ми генеруємо ізольовані фікстури через factory_boy з транзакціями та rollback, що дає стабільність і повторюваність.

Як AI генерує інтеграційні тести?

Використовуємо зв'язку LangChain + ChatOpenAI (GPT-4o з temperature 0.1 для детермінованості). Генерація проходить у кілька проходів: спочатку аналіз схеми та контрактів, потім створення коду, потім валідація синтаксису та запуск на mock-оточенні. Фінальний код тестів відповідає стандартам pytest і готовий до включення в репозиторій.

Кейс з нашої практики: e-commerce платформа, 15 мікросервісів. Проблема: інтеграційне тестування робилося вручну перед кожним релізом (2 QA × 3 дні). Ми згенерували 180 інтеграційних тестів для критичних шляхів: замовлення → оплата → сповіщення → оновлення складу. З 180 тестів при першому запуску впало 23 — знайшли реальні баги: помилки в обробці currency conversion, дублювання подій в черзі, неправильний статус при partial payment. Після виправлення coverage з інтеграцій виріс з 15% до 85%, а час регресії скоротився з 3 днів до 4 годин. Клієнт скоротив витрати на тестування на 40%.

from langchain_openai import ChatOpenAI
import json
from pathlib import Path


class IntegrationTestGenerator:
    INTEGRATION_PROMPT = """Створи інтеграційний тест для взаємодії компонентів.
Компоненти та їх контракти: {components}
Схема бази даних: {db_schema}
Інтеграційний сценарій: {scenario}
Вимоги:
- pytest + SQLAlchemy для роботи з БД (використовуй транзакції з rollback)
- httpx.AsyncClient для HTTP-викликів
- pytest-asyncio для async тестів
- Тестова база даних через pytest fixture (не бойова!)
- Перевіряй не лише HTTP-статус, але й стан в БД після операції
- Використовуй factory_boy або pytest-factoryboy для тестових даних
Поверни повний код тесту з fixtures."""

    def __init__(self):
        self.llm = ChatOpenAI(model="gpt-4o", temperature=0.1)

    def generate_db_integration_tests(
        self, model_code: str, repository_code: str, db_schema: str
    ) -> str:
        prompt = f"""Створи pytest інтеграційні тести для Repository та Model.
SQLAlchemy Model:
```python
{model_code}
"}

Repository:

{repository_code} 

DDL схема:

{db_schema} 

Створи тести:

1. CRUD операції (create, read, update, delete)
2. Фільтрація та сортування
3. Транзакції (успішний commit, rollback при помилці)
4. Унікальні обмеження (спроба вставити дублікат)
5. Foreign key constraints
6. Пагінація (якщо є в Repository)

Fixtures:

• db_session: SQLAlchemy session з rollback після кожного тесту
• test_data factories через factory_boy

Поверни код тестів.""" return self.llm.invoke(prompt).content

def generate_service_integration_tests(
    self,
    service_a_spec: dict,
    service_b_spec: dict,
    interaction_patterns: list[str],
) -> str:
    """Генерує тести для взаємодії між сервісами"""
    prompt = f"""Створи pytest інтеграційні тести для взаємодії сервісів.
"""

Сервіс A (клієнт):

• Base URL: {service_a_spec['base_url']}
• Викликає: {json.dumps(service_a_spec['calls'], ensure_ascii=False)}

Сервіс B (сервер):

• Endpoints: {json.dumps(service_b_spec.get('endpoints', []), ensure_ascii=False)}

Паттерни взаємодії: {chr(10).join(f"- {p}" for p in interaction_patterns)} Використовуй:

• pytest + respx для мокування HTTP-відповідей сервісу B
• Тести на retry-логіку (що відбувається при тайм-ауті сервісу B)
• Тести на circuit breaker (якщо є)
• Тести на коректну обробку 4xx/5xx від сервісу B

Поверни код тестів з fixtures.""" return self.llm.invoke(prompt).content

## Генерація фікстур та тестових даних
```python
class TestDataGenerator:
    FACTORY_PROMPT = """Створи factory_boy factories для моделей.
SQLAlchemy моделі: {models_code}
Створи:
1. Factory для кожної моделі
2. SubFactory для пов'язаних об'єктів
3. Trait для специфічних станів (напр. expired_user, admin_user)
4. Batch-створення через factory.build_batch
Поверни код factories."""

    async def generate_factories(self, models_code: str) -> str:
        result = await self.llm.ainvoke(
            self.FACTORY_PROMPT.format(models_code=models_code)
        )
        return result.content

    async def generate_fixtures_from_schema(self, schema: dict) -> str:
        """Створює pytest fixtures зі схеми БД"""
        prompt = f"""Створи pytest fixtures для тестової бази даних.
Схема: {json.dumps(schema, ensure_ascii=False, indent=2)}
Fixtures потрібні:
- engine: SQLAlchemy engine до test DB (PostgreSQL через pytest-postgresql)
- db_session: сесія з rollback після кожного тесту
- Fixtures для кожної таблиці: мінімальний валідний об'єкт
- seeded_db: база з початковими даними для e2e тестів
Використовуй scope='function' для db_session, scope='session' для engine.
Поверни Python код."""
        return (await self.llm.ainvoke(prompt)).content
```

Для черг повідомлень (RabbitMQ/Kafka) ми використовуємо testcontainers-python, генеруючи тести з перевіркою відправки, обробки та dead letter queue. Детальні приклади — в індивідуальній консультації.

Чому AI-генерація надійніша за ручне написання?

AI-тести в 5 разів швидше створюються і забезпечують покриття на рівні 80–90% проти 10–20% при ручній роботі. Вони перевіряють всі інтеграційні шляхи, включаючи граничні випадки та обробку помилок, які QA часто пропускають. Крім того, згенеровані тести не залежать від бойових даних і стабільні при змінах схеми.

Що входить в роботу?

Порівняння ручного та AI-підходу

Гарантія якості згенерованих тестів

Кожен згенерований тест проходить двоетапну перевірку: синтаксичний аналіз за допомогою pytest --co та запуск в ізольованому staging-оточенні з реальними залежностями. Ми фіксуємо coverage на рівні модуля і виправляємо всі хибні спрацьовування. Досвід показує, що 90% тестів проходять з першого разу. Решта 10% — це граничні випадки, які ми доопрацьовуємо вручну. В результаті клієнти отримують стабільний набір тестів, готовий до інтеграції в pytest пайплайн.

Терміни орієнтовно

• Базовий пакет (БД + сервіси): від 3 до 5 тижнів.
• Повний пакет (БД + сервіси + черги + testcontainers): від 5 до 7 тижнів.

Вартість розраховується індивідуально після аудиту проєкту. Зв'яжіться з нами для оцінки вашого проєкту. Заповніть форму на сайті, і ми оцінимо обсяг робіт за 1 робочий день.

AI-генерація не пропускає жоден endpoint, не забуває про dead letter queue і не помиляється в типізованих asserts. Покриття інтеграційними тестами зростає з 10–20% до 80–90% за один цикл генерації. Наші інженери гарантують, що згенеровані тести проходять код-рев'ю і готові до запуску в CI.

Замовте впровадження AI-генерації тестів зараз і отримайте консультацію інженера. Зв'яжіться з нами — ми допоможемо прискорити регресійне тестування та знизити витрати.