behave-creatorlisted

# Behave Test Writer ## Overview Write BDD tests that exercise real code paths, not test framework mechanics. Tests should verify business logic through actual repository and service classes, with test data visible in Gherkin tables. **Core principle:** If your test passes without calling production code, it's testing the wrong thing. ## When to Use - Writing new feature files or step definitions - Debugging "undefined step" errors - Tests pass but don't verify actual persistence - Converting unit tests to integration/BDD tests - Test data is hidden in step definitions ## Feature file layout Place new ``*.feature`` files under ``features/<domain>/``, aligned with ``${user_config.src_root}/<domain>/`` when a matching domain exists (see ``features/README.md`` for the full map). Step definitions stay in the flat ``features/steps/`` pool; mockdata/pages already use ``features/mockdata/<domain>/`` and ``features/pages/<domain>/``. The pre-push hook discovers features recursively and groups parallel units by subfolder name. ## When NOT to Use Behave **Move these to pytest instead:** | Test Type | Example | Why Pytest | |-----------|---------|------------| | Entity CRUD | "Insert and retrieve record" | No workflow, just ORM verification | | API smoke tests | "API returns 200" | Connectivity check, not business logic | | Method return types | "Returns DTO" | Unit/integration test concern | | Parameterized edge cases | "Score boundaries" | `@pytest.mark.parametrize` is clean