nexent-python-tests

# Nexent traditional Python unit tests Paths below are relative to the repository root. These tests are a permanently maintained suite kept separate from the requirement-driven D1-D5 system. Historical documents may call it Legacy UT; that does not mean planned removal. Do not assign formal D1-D5 Case IDs to UT, bind it under `test-e2e/cases/`, or count it in the generated functional baseline. Use `nexent-test-assets` for formal Cases. Isolated validation, arithmetic, local branches and error conversion belong primarily here, including when adding tests after code is already developed. Read existing inputs/assertions before adding another test; reuse adequate coverage or strengthen missing variants in its owning suite. Do not copy/wrap UT as formal D1 solely for a Feature link, Case count or report entry. New formal D1 requires distinct component-contract evidence with real internal collaboration through nexent-test-assets; an API/runtime boundary may legitimately verify the same rule again. Preserve existing D1 rather than bulk deleting or relabeling overlaps. For formal test backfill, use nexent-test-assets' test-backfill mode; UT results remain separate. For every product-code change, assess applicable unit behavior and document reuse, strengthen, add or a justified non-behavior exemption. New or changed behavior requires success, boundary and error coverage. Bugfixes require a regression assertion that detects the defect; demonstrate failure before the fix where feasible. Existing adequate coverage may be reused without artificial file edits. Derive expected behavior from requirements/contracts, not merely the implementation. Relevant local UT verification is mandatory before a product-code PR; CI independently runs its configured UT set. Failures, collection errors and unavailable execution are not passes. UT does not replace required component/API/runtime/journey/risk acceptance. 1. Identify the unit and behavior. Inspect neighboring tests, `test/conftest.py`, and `test/pytest.ini` before changing fixture/import setup. 2. Use pytest exclusively, pytest assertions, fixtures, and `pytest-mock`. Files/functions start with `test_`; test classes start with `Test`. Keep files below 500 lines or split by feature using `test_<module>_<feature>.py`; split package directories include `__init__.py`. 3. Import the unit and necessary test helpers. Mock collaborators rather than exercising external interfaces/clients/services. Patch the fully qualified lookup site determined from actual imports, not the dependency's definition module. For example, if `backend.services.example_service` imports `fetch` using `from provider import fetch`, patch `backend.services.example_service.fetch`. If the runtime loads the module as `services.example_service`, use that actual path. Do not copy an unrelated service path from an example. 4. Isolate external I/O and APIs. Reset mutable state with fixtures; use `autouse=True` when every test in a scope requires it. Do not mock away the behavior being asserted. 5. Cover changed success/error flows and boundaries with specific observable assertions. Use `side_effect` for collaborator errors, `@pytest.mark.parametrize` for variants, and `@pytest.mark.asyncio` for async tests. Async collaborators need awaitable mocks. 6. Order imports as standard library, third-party, then project; write comments/docstrings in English. 7. Run narrow tests from the root with a working backend environment, such as `pytest test/backend/apps/test_agent_app.py -v`. Broaden when needed; `python test/run_all_test.py` is the existing broad runner. Report commands, selected tests, results, reuse rationale and environment blockers in the change's verification record, separately from formal Case IDs. Do not recreate the complete historical suite for each change. Python coverage uses backend/sdk; frontend coverage remains separate. Do not impose a new threshold or edit CI from this skill without authorization. Unit-test isolation does not replace live-service functional checks or real-model acceptance.