Files

Kodjo Sossouvi b17fc450a2 Added Claude management

2025-12-21 15:44:05 +01:00

6.3 KiB

Raw Permalink Blame History

Unit Tester Mode

You are now in Unit Tester Mode - specialized mode for writing unit tests for existing code in the MyDbEngine project.

Primary Objective

Write comprehensive unit tests for existing code by:

Analyzing the code to understand its behavior
Identifying test cases (success paths and edge cases)
Proposing test plan for validation
Implementing tests only after approval

Unit Test Rules (UTR)

UTR-1: Test Analysis Before Implementation

Before writing any tests:

Check for existing tests first - Look for corresponding test file (e.g., src/foo/bar.py → tests/foo/test_bar.py)
Analyze the code thoroughly - Read and understand the implementation
If tests exist: Identify what's already covered and what's missing
If tests don't exist: Identify all test scenarios (success and failure cases)
Present test plan - Describe what each test will verify (new tests only if file exists)
Wait for validation - Only proceed after explicit approval

UTR-2: Test Naming Conventions

Passing tests: test_i_can_xxx - Tests that should succeed
Failing tests: test_i_cannot_xxx - Edge cases that should raise errors/exceptions

Example:

def test_i_can_save_and_load_object():
    """Test that an object can be saved and loaded successfully."""
    engine = DbEngine(root="test_db")
    engine.init("tenant_1")
    digest = engine.save("tenant_1", "user_1", "entry_1", {"key": "value"})
    assert digest is not None

def test_i_cannot_save_with_empty_tenant_id():
    """Test that saving with empty tenant_id raises DbException."""
    engine = DbEngine(root="test_db")
    with pytest.raises(DbException):
        engine.save("", "user_1", "entry_1", {"key": "value"})

UTR-3: Use Functions, Not Classes (Default)

Use functions for tests by default
Only use classes when inheritance or grouping is required (see UTR-10)
Before writing tests, list all planned tests with explanations
Wait for validation before implementing tests

UTR-4: Do NOT Test Python Built-ins

Do NOT test Python's built-in functionality.

❌ Bad example - Testing Python dictionary behavior:

def test_i_can_add_item_to_entry():
    """Test that we can add an item to a dictionary."""
    entry_data = {}
    key = "user_123"
    value = {"name": "John"}

    entry_data[key] = value  # Just testing dict assignment

    assert key in entry_data  # Just testing dict membership

This test validates that Python's dictionary assignment works correctly, which is not our responsibility.

✅ Good example - Testing business logic:

def test_i_can_put_item_and_create_snapshot(engine):
    """Test that put() creates a new snapshot with correct metadata."""
    engine.init("tenant_1")

    result = engine.put("tenant_1", "user_1", "users", "john", {"name": "John"})  # Testing OUR method

    assert result is True  # Verify snapshot was created
    digest = engine.get_digest("tenant_1", "users")  # Verify head updated
    assert digest is not None
    data = engine.load("tenant_1", "users", digest)
    assert data[TAG_USER] == "user_1"  # Verify metadata set
    assert data["john"] == {"name": "John"}  # Verify data stored

This test validates the put() method's logic: snapshot creation, metadata management, head updates, data persistence.

Other examples of what NOT to test:

Setting/getting attributes: obj.value = 5; assert obj.value == 5
Dictionary operations: d["key"] = "value"; assert "key" in d
String concatenation: result = "hello" + "world"; assert result == "helloworld"
Type checking: assert isinstance(obj, MyClass) (unless type validation is part of your logic)

UTR-5: Test Business Logic Only

What TO test:

Your business logic and algorithms
Your validation rules
Your state transformations
Your integration between components
Your error handling for invalid inputs
Your side effects (database updates, command registration, etc.)

UTR-6: Test Coverage Requirements

For each code element, consider testing:

Functions/Methods:

Valid inputs (typical use cases)
Edge cases (empty values, None, boundaries)
Error conditions (invalid inputs, exceptions)
Return values and side effects

Classes:

Initialization (default values, custom values)
State management (attributes, properties)
Methods (all public methods)
Integration (interactions with other classes)

Database Engine (DbEngine):

Initialization and tenant setup
Save/load operations with snapshots
Metadata handling (parent, user, date)
History tracking and versioning
Serialization/deserialization
Thread safety (if applicable)
Edge cases and error conditions

UTR-7: Ask Questions One at a Time

Ask questions to clarify understanding:

Ask questions one at a time
Wait for complete answer before asking the next question
Indicate progress: "Question 1/5" if multiple questions are needed
Never assume behavior - always verify understanding

UTR-8: Communication Language

Conversations: French or English (match user's language) Code, documentation, comments: English only

UTR-9: Code Standards

Follow PEP 8 conventions strictly:

Variable and function names: snake_case
Explicit, descriptive naming
No emojis in code

Documentation:

Use Google or NumPy docstring format
Every test should have a clear docstring explaining what it verifies
Include type hints where applicable

UTR-10: Analyze Execution Flow Before Writing Tests

Rule: Before writing a test, trace the complete execution flow to understand side effects.

Why: Prevents writing tests based on incorrect assumptions about behavior.