Generate integration tests for multiple interacting components in Python. Use when testing interactions between: (1) Multiple services or APIs (REST/GraphQL endpoints, microservices), (2) Database operations with repositories/ORMs (SQLAlchemy, Django ORM), (3) External services (payment gateways, email services, third-party APIs), (4) Message queues and event-driven systems, (5) Full stack workflows (API + database + business logic). Provides test structure templates, fixtures, test data builders, and patterns for pytest-based integration testing.
npx skills add https://github.com/ArabelaTso/Skills-4-SE --skill integration-test-generator
Generate comprehensive integration tests for Python applications that test multiple interacting components together.
Integration tests verify that multiple components work correctly together:
import pytest
from myapp.services import ServiceA, ServiceB
class TestServiceIntegration:
"""Test integration between ServiceA and ServiceB."""
@pytest.fixture
def service_a(self):
"""Setup ServiceA with test configuration."""
return ServiceA(config={"mode": "test"})
@pytest.fixture
def service_b(self, service_a):
"""Setup ServiceB that depends on ServiceA."""
return ServiceB(service_a=service_a)
def test_services_communicate_correctly(self, service_a, service_b):
"""Test that ServiceB correctly uses ServiceA."""
# Arrange
test_data = {"key": "value"}
# Act
service_a.store(test_data)
result = service_b.process()
# Assert
assert result["key"] == "value"
assert result["processed"] is True
Use fixtures to set up and tear down test dependencies:
@pytest.fixture(scope="function")
def db_session():
"""Create a fresh database for each test."""
engine = create_engine("sqlite:///:memory:")
Base.metadata.create_all(engine)
Session = sessionmaker(bind=engine)
session = Session()
yield session # Test runs here
session.close()
@pytest.fixture
def test_user(db_session):
"""Create a test user and clean up after test."""
user = User(username="testuser", email="[email protected]")
db_session.add(user)
db_session.commit()
yield user
db_session.delete(user)
db_session.commit()
Test multiple API endpoints working together:
def test_create_user_then_create_order(test_client):
# Create user
user_response = test_client.post("/api/users", json={"username": "test"})
user_id = user_response.json()["id"]
# Create order for user
order_response = test_client.post(
"/api/orders",
json={"user_id": user_id, "items": [...]}
)
# Verify integration
assert order_response.status_code == 201
assert order_response.json()["user_id"] == user_id
Test repository interactions and transactions:
def test_user_order_relationship(db_session, user_repo, order_repo):
# Create user
user = user_repo.create(username="test")
db_session.commit()
# Create orders
order1 = order_repo.create(user_id=user.id, total=50.00)
order2 = order_repo.create(user_id=user.id, total=75.00)
db_session.commit()
# Verify relationship
retrieved_user = user_repo.get_by_id(user.id)
assert len(retrieved_user.orders) == 2
Test integration with external APIs using mocks:
import responses
@responses.activate
def test_payment_integration():
# Mock external payment API
responses.add(
responses.POST,
"https://api.payment.com/charge",
json={"transaction_id": "txn_123", "status": "success"},
status=200
)
# Test integration
payment_service = PaymentService()
result = payment_service.charge(amount=99.99, card_token="tok_test")
assert result["status"] == "success"
assert len(responses.calls) == 1
For comprehensive integration test patterns, see:
patterns.md - Detailed examples for:
test_data.md - Test data builders and fixtures:
Each test should be independent:
@pytest.fixture(scope="function") # New instance per test
def db_session():
# Fresh database for each test
engine = create_engine("sqlite:///:memory:")
Base.metadata.create_all(engine)
# ...
Always clean up test data:
@pytest.fixture
def test_resource():
# Setup
resource = create_resource()
yield resource
# Teardown - always runs even if test fails
delete_resource(resource)
Create reusable test data builders:
def make_user(username="test", **kwargs):
defaults = {"email": f"{username}@example.com", "is_active": True}
return User(**{**defaults, **kwargs, "username": username})
# Usage
admin = make_user("admin", role="admin")
inactive = make_user("inactive", is_active=False)
Test complete user workflows:
def test_complete_checkout_workflow(test_client, db_session):
# 1. Create user
user = create_test_user()
# 2. Add items to cart
add_to_cart(user.id, product_id=1, quantity=2)
# 3. Checkout
order = checkout(user.id, payment_method="credit_card")
# 4. Verify all integrations
assert order.status == "confirmed"
assert order.user_id == user.id
assert len(order.items) == 1
assert get_cart(user.id).items == [] # Cart emptied
Use mocks for external services to avoid network calls:
from unittest.mock import Mock, patch
def test_with_mocked_email_service():
with patch('myapp.services.EmailService') as mock_email:
mock_email.send.return_value = {"message_id": "123"}
# Test code that uses email service
result = send_confirmation_email("[email protected]")
# Verify mock was called correctly
mock_email.send.assert_called_once()
assert result["message_id"] == "123"
# Run all integration tests
pytest tests/integration/
# Run specific test file
pytest tests/integration/test_user_order.py
# Run tests matching pattern
pytest -k "test_integration"
# Run with verbose output
pytest -v tests/integration/
# Run with coverage
pytest --cov=myapp tests/integration/
# Database session
@pytest.fixture(scope="function")
def db_session():
"""Fresh database for each test."""
# Test client for API testing
@pytest.fixture
def test_client():
"""Test client for FastAPI/Flask app."""
with TestClient(app) as client:
yield client
# Mock external service
@pytest.fixture
def mock_payment_gateway():
with patch('myapp.services.PaymentGateway') as mock:
yield mock
# Verify status codes
assert response.status_code == 201
# Verify data structure
assert "id" in response.json()
assert len(response.json()["items"]) == 2
# Verify relationships
assert order.user_id == user.id
assert user.orders[0].id == order.id
# Verify side effects
assert email_service.send.called
assert db_session.query(Order).count() == 1
LLM-driven hypothesis generation/testing on tabular data. Three methods: HypoGeniC (data-driven), HypoRefine (literature+data), Union. Iterative refinement, Redis caching, multi-hypothesis inference. Manual: hypothesis-generation; ideation: scientific-brainstorming.
This skill should be used when the user asks to \"automate SQL injection testing,\" \"enumerate database structure,\" \"extract database credentials using sqlmap,\" \"dump tables and columns...
Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.
Bisect a ClickHouse regression using pre-built master binaries from CI. Use when the user wants to find the commit that introduced a bug.
QA an analysis before sharing -- methodology, accuracy, and bias checks. Use when reviewing an analysis before a stakeholder presentation, spot-checking calculations and aggregation logic, verifying a SQL query's results look right, or assessing whether conclusions are actually supported by the data.
End-to-end smoke test for the public Errors HTTP API (error groups). Seeds failed runs into ClickHouse so the error materialized views populate, then drives the real endpoints against the running webapp — list (with filters + pagination), retrieve, resolve/ignore/unresolve, the `filter[error]` runs filter, user attribution via the `trigger.dev mint-token` -> JWT exchange, and the 401/403/404 negatives. Use for "smoke test the errors API", "test the errors API e2e", "prove the errors endpoints work", or to re-verify after changes.
Strix SQL 注入测试手册,覆盖 union、blind、error-based 与 ORM 绕过技巧;触发名:strix-sql-injection
> Pull and interpret production experiment query-performance data from the staff-only slowest experiment queries, precompute read/build health, and preaggregation cache footprint. and response field semantics (exception codes, exposure paths, precompute skip reasons, job states). Use when investigating slow or failing experiment queries, precompute regressions, 307/159/241 errors, preaggregation table growth, or when asked how experiment query performance or the precompute rollout is doing in production.
Take arabelatso/integration-test-generator from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.