0Pricing
AI Agents · Lekcja

Testy integracyjne potoków agentów

Testy end-to-end wobec rzeczywistych usług w odizolowanych środowiskach testowych.

Testy integracyjne potoków agentów to bezpłatna lekcja AI Agents na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Agents, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Agents zawiera 4 lekcji w sumie.

Czym są testy integracyjne agentów?

Testy jednostkowe sprawdzają pojedyncze komponenty w izolacji. Testy integracyjne sprawdzają, czy wiele komponentów współdziała poprawnie w rzeczywistym lub zbliżonym do rzeczywistego środowisku.

W przypadku agentów oznacza to uruchomienie całego potoku — wywołań LLM, wykonywania narzędzi i przechowywania danych — z użyciem rzeczywistych usług lub usług w piaskownicy.

Struktura testu end-to-end

Test end-to-end agenta wysyła rzeczywiste zapytanie przez cały potok i weryfikuje końcowy wynik. Należy uruchamiać te testy w środowisku piaskownicy — nigdy przeciwko produkcyjnej bazie danych ani aktywnym danym użytkowników.

import pytest

# Mark as integration test — skipped in fast unit test runs
@pytest.mark.integration
def test_research_agent_full_pipeline():
    from myagent import ResearchAgent

    agent = ResearchAgent(
        openai_api_key='YOUR_TEST_KEY',
        search_api_key='YOUR_TEST_KEY'
    )

    result = agent.run('What is the population of Tokyo?')

    # Structural assertions — not exact string matching
    assert isinstance(result, dict)
    assert result['status'] == 'completed'
    assert 'tokyo' in result['answer'].lower() or 'japan' in result['answer'].lower()
    assert len(result['sources']) >= 1

Izolacja danych testowych

Testy integracyjne nie mogą zanieczyszczać współdzielonych danych. Należy używać dedykowanych baz testowych, odizolowanych przestrzeni nazw lub tymczasowych danych usuwanych po zakończeniu testu. Nigdy nie należy zapisywać danych testowych w tabelach produkcyjnych.

import os
import pytest

# Use a separate test database URL
@pytest.fixture(scope='session')
def test_db():
    test_db_url = os.environ.get(
        'TEST_DATABASE_URL',
        'postgresql://localhost/myagent_test'  # separate test DB
    )
    # Set up test schema
    from myagent.database import create_tables
    create_tables(test_db_url)
    yield test_db_url
    # Tear down after all tests in the session
    from myagent.database import drop_tables
    drop_tables(test_db_url)

Czyszczenie po każdym teście

Każdy test integracyjny powinien usuwać wszystkie utworzone przez siebie dane. Należy użyć wzorca fixture z yield w pytest: konfigurację wykonać przed yield, a czyszczenie po nim. Dzięki temu testy są niezależne i mogą być uruchamiane w dowolnej kolejności.

import pytest

@pytest.fixture
def clean_agent_memory(test_db):
    # No setup needed — DB starts empty
    yield
    # Cleanup: delete any records created during this test
    from myagent.database import clear_conversation_history
    clear_conversation_history(test_db)

@pytest.mark.integration
def test_agent_stores_conversation(clean_agent_memory, test_db):
    from myagent import Agent
    agent = Agent(db_url=test_db)

    agent.run('Remember that my name is Alex')
    history = agent.get_history()

    assert len(history) > 0
    assert any('Alex' in str(msg) for msg in history)
    # clean_agent_memory fixture deletes these after the test

Usługi w piaskownicy: testowe klucze API

W testach integracyjnych należy używać dedykowanych testowych kluczy API z ograniczonymi uprawnieniami i limitami. Nigdy nie należy używać kluczy produkcyjnych w CI. Klucze testowe należy przechowywać jako zmienne środowiskowe CI, a nie w kodzie.

import os
import pytest

# Skip integration tests if test keys are not configured
def requires_integration_keys():
    return pytest.mark.skipif(
        not os.environ.get('OPENAI_TEST_KEY'),
        reason='Integration test keys not configured'
    )

@requires_integration_keys()
@pytest.mark.integration
def test_live_weather_tool():
    from myagent.tools import get_weather
    result = get_weather(city='London', unit='celsius')

    assert result['success'] is True
    assert 'temperature' in result
    assert isinstance(result['temperature'], (int, float))

Korzystanie z Dockera dla baz danych w piaskownicy

W przypadku testów integracyjnych wymagających rzeczywistej bazy danych należy uruchomić kontener Dockera na czas sesji testowej. Gwarantuje to za każdym razem czystą, odizolowaną bazę i zapobiega konfliktom z bazą deweloperską.

# conftest.py — docker-based test database
import subprocess
import pytest

@pytest.fixture(scope='session')
def docker_postgres():
    container_id = subprocess.check_output([
        'docker', 'run', '-d',
        '-e', 'POSTGRES_PASSWORD=test',
        '-e', 'POSTGRES_DB=agent_test',
        '-p', '5434:5432',  # use non-standard port to avoid conflicts
        'postgres:15'
    ]).decode().strip()

    import time
    time.sleep(2)  # wait for Postgres to start

    yield 'postgresql://postgres:test@localhost:5434/agent_test'

    subprocess.run(['docker', 'stop', container_id])
    subprocess.run(['docker', 'rm', container_id])

Konfiguracje testowe zależne od środowiska

Testy integracyjne wymagają różnych konfiguracji dla środowisk lokalnych, CI i staging. Należy używać zmiennych środowiskowych oraz pomocnika konfiguracji, który automatycznie wybiera właściwe ustawienia.

import os

def get_test_config() -> dict:
    env = os.environ.get('TEST_ENV', 'local')

    configs = {
        'local': {
            'db_url': 'postgresql://localhost/agent_test',
            'openai_key': os.environ.get('OPENAI_TEST_KEY', ''),
            'use_real_llm': False  # use mocks locally
        },
        'ci': {
            'db_url': os.environ.get('CI_DATABASE_URL', ''),
            'openai_key': os.environ.get('CI_OPENAI_KEY', ''),
            'use_real_llm': True  # use real LLM in CI integration tests
        },
        'staging': {
            'db_url': os.environ.get('STAGING_DATABASE_URL', ''),
            'openai_key': os.environ.get('STAGING_OPENAI_KEY', ''),
            'use_real_llm': True
        }
    }
    return configs[env]

config = get_test_config()

print(f"TEST_ENV not set -> using '{os.environ.get('TEST_ENV', 'local')}' config")
print(f"DB URL       : {config['db_url']}")
print(f"Use real LLM : {config['use_real_llm']}")

Markery pytest do wyboru testów

Niestandardowe markery pytest pozwalają kategoryzować testy i uruchamiać tylko odpowiedni podzbiór. Markery należy skonfigurować w pliku pytest.ini, a następnie używać -m w wierszu poleceń do ich wyboru.

# pytest.ini
# [pytest]
# markers =
#     unit: Fast unit tests with mocked dependencies
#     integration: Slower tests with real or sandboxed services
#     expensive: Tests that make real LLM calls and cost money

# Run only unit tests (fast CI check):
# pytest -m unit

# Run only integration tests:
# pytest -m integration

# Run everything except expensive tests:
# pytest -m 'not expensive'

# In test files:
import pytest

@pytest.mark.unit
def test_tool_format():
    pass  # fast, no external calls

@pytest.mark.integration
@pytest.mark.expensive
def test_with_real_llm():
    pass  # slow, costs tokens

Uruchamianie testów integracyjnych w CI

Należy skonfigurować potok CI (GitHub Actions, GitLab CI), aby uruchamiać testy jednostkowe przy każdym pushu, a integracyjne zgodnie z harmonogramem lub przed wydaniami. Zapewnia to równowagę między szybkością a zakresem testów.

# .github/workflows/test.yml (abbreviated)
# name: Tests
# on:
#   push:
#     branches: [main, develop]
#   schedule:
#     - cron: '0 2 * * *'  # nightly integration tests
#
# jobs:
#   unit-tests:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v3
#       - run: pip install -r requirements.txt
#       - run: pytest -m unit --tb=short
#
#   integration-tests:
#     if: github.event_name == 'schedule'
#     env:
#       CI_OPENAI_KEY: ${{ secrets.CI_OPENAI_KEY }}
#       CI_DATABASE_URL: ${{ secrets.CI_DATABASE_URL }}
#     steps:
#       - run: pytest -m integration --tb=long

print('Unit tests on every push, integration tests nightly')

Pomiar pokrycia testami agentów

Należy użyć pytest-cov do pomiaru, które wiersze kodu agenta są objęte testami. Warto dążyć do wysokiego pokrycia funkcji narzędzi i logiki orkiestracji agenta, nawet gdy wywołania LLM są mockowane.

# Install: pip install pytest-cov

# Run tests with coverage report:
# pytest --cov=myagent --cov-report=html -m unit

# This generates an HTML report showing which lines are untested
# Uncovered lines in the agent loop are high-risk areas

# Example coverage config in pyproject.toml:
# [tool.coverage.run]
# omit = ["tests/*", "scripts/*"]
#
# [tool.coverage.report]
# fail_under = 80  # fail if coverage drops below 80%

print('Coverage reports highlight untested code paths in your agent')

Podsumowanie dobrych praktyk testów integracyjnych

Najważniejsze zasady niezawodnych testów integracyjnych agentów:

  • Zawsze używać oddzielnych baz testowych — nigdy bazy produkcyjnej
  • Usuwać dane testowe po każdym teście za pomocą fixture'ów z yield
  • Używać dedykowanych testowych kluczy API z ograniczonymi limitami
  • Używać markerów pytest do oddzielania szybkich testów jednostkowych od wolnych testów integracyjnych
  • Uruchamiać testy jednostkowe przy każdym pushu, a testy integracyjne zgodnie z harmonogramem
  • Używać Dockera do tworzenia tymczasowych, czystych środowisk baz danych

Sprawdzenie wiedzy: Testy integracyjne

Sprawdź swoją wiedzę na temat testowania integracyjnego potoków agentów.

Podsumowanie: Testy integracyjne potoków agentów

Można już tworzyć kompletny i niezawodny zestaw testów integracyjnych:

  • Należy używać @pytest.mark.integration do oddzielania wolnych testów od szybkich testów jednostkowych
  • Należy izolować dane testowe za pomocą dedykowanych baz i fixture'ów czyszczących dane
  • Należy używać Dockera lub usług w piaskownicy do tworzenia czystych środowisk
  • Należy konfigurować klucze API przeznaczone do testów za pomocą zmiennych środowiskowych
  • Należy uruchamiać testy jednostkowe przy każdym commicie, a testy integracyjne co noc w CI
  • Należy mierzyć pokrycie za pomocą pytest-cov, aby znajdować nieprzetestowane ścieżki

Dobrze zorganizowana piramida testów pomaga zachować niezawodność agenta w miarę jego rozwoju.

Często zadawane pytania

Czy lekcja „Testy integracyjne potoków agentów” jest bezpłatna?

Tak — pełny tekst „Testy integracyjne potoków agentów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Agents, przejdź na CoddyKit PRO. Kurs AI Agents zawiera 4 lekcji w sumie.

Co nauczysz się w „Testy integracyjne potoków agentów”?

Testy end-to-end wobec rzeczywistych usług w odizolowanych środowiskach testowych. Ćwiczysz AI Agents z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI Agents?

Nie wymagamy żadnego doświadczenia. AI Agents w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Testy integracyjne potoków agentów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI Agents?

Tak. Każda lekcja AI Agents zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Dlaczego testowanie agentów jest inne
  2. Mockowanie wywołań LLM w testach
  3. Testowanie agentów oparte na asercjach
  4. Testy integracyjne potoków agentów
← Powrót do AI Agents