Run any Skill in Manus with one click

backend-tests

Stars114

Forks56

UpdatedJuly 17, 2026 at 16:24

How to run and add Python tests in the Massing API/data services. Invoke when writing or running backend tests, or debugging a CI test-gate failure. Covers the run_tests.py runner, the manifest guard, per-test env isolation, DB-lock cleanup, and the two idioms (DB-backed vs engine/IFC).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ibuilder

ibuilder/massing

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	backend-tests
description	How to run and add Python tests in the Massing API/data services. Invoke when writing or running backend tests, or debugging a CI test-gate failure. Covers the run_tests.py runner, the manifest guard, per-test env isolation, DB-lock cleanup, and the two idioms (DB-backed vs engine/IFC).

Massing backend tests

There is no pytest. Tests are self-contained test_*.py scripts in services/api/ that spin up their own TestClient, assert, print a one-line summary, and exit non-zero on failure.

Run

cd services/api
PYTHONPATH="src;../data/src" ./.venv/Scripts/python.exe -X utf8 run_tests.py     # whole suite (~40 min)
PYTHONPATH="src;../data/src" ./.venv/Scripts/python.exe -X utf8 test_<name>.py    # one test

Use -X utf8 — some tests print →/²/³ and crash on the default Windows cp1252 console (a false failure; CI uses utf-8).

The manifest guard — REGISTER NEW TESTS

run_tests.py has a hand-maintained TESTS list and a _manifest_guard() that fails the whole run if any test_*.py on disk isn't in the list. After adding test_foo.py, add "test_foo" to the TESTS list or CI fails before running anything.

Two test idioms

DB-backed API test: set os.environ["DATABASE_URL"], STORAGE_DIR, and (if it uploads a source IFC) IFC_DIR — all to ./test_*-prefixed local paths (gitignored). os.environ.pop("AEC_RBAC", None). Use TestClient(app) + X-User header. Upload a model via POST /projects/{pid}/source-ifc?publish=false.
Engine/IFC test: prepend ../data/src to sys.path, build a model with aec_data.massing.generate_blank_ifc + aec_data.edit.*, and assert on aec_data/aec_api engine functions directly (no DB needed).

Gotchas

Local DB lock: a killed test can leave test_*.db locked ("Device or resource busy"). Clean rm -f ./test_<name>.db; rm -rf ./test_storage_<name> ./test_ifc_<name> before re-running; if truly stuck, run a throwaway copy with a different db name to verify logic (CI runs clean).
edit_history sidecar: tests that author edits leave state under STORAGE_DIR; clean it between local runs (run_tests.py does this per-test).
Infinite SSE endpoints HANG under TestClient (c.stream + iter_lines never returns). Test the payload/signature logic, not the live stream.
app.routes introspection is unreliable for included-router paths — assert via a real TestClient call instead.
CI ruff runs from services/api with its ruff.toml (isort). See the ship-release skill.

See memory: backend-test-runner, ruff-ci-config-gotcha.

More from this repository

same repository

master-builder

ibuilder/massing

Reason like a master builder — one mind holding an entire built-asset project from raw land through design, construction, handover, operations, and disposition, anywhere in the world. Use whenever the user touches real estate development, construction, or the built environment: site feasibility, highest-and-best-use, entitlements/zoning/planning permission, building-code compliance in any jurisdiction, structural/MEP/envelope questions, delivery-method selection, estimating, scheduling, procurement, construction administration (RFIs, submittals, change orders, pay apps), BIM/IFC/ISO 19650 workflows, development pro formas, JV waterfalls, construction-loan mechanics, cap rates, IRR, or underwriting. Trigger even when the user names only a slice (e.g. "what wind load applies in Miami", "draft an RFI", "does this deal pencil") — the point is reasoning about that slice inside the whole project. Also trigger for any request to build, price, phase, or evaluate a project in an unfamiliar place.

2026-07-20114

security-monitoring

ibuilder/massing

How to monitor and fix security issues in Massing — CodeQL alerts, dependency audits, secret scanning, and ReDoS/XXE fixes. Invoke after a push (standing directive) or when doing a hardening pass. Emphasises that a green CodeQL *run* != zero alerts.

2026-07-19114

massing-bim

ibuilder/massing

Drive a Massing BIM/AEC project from an AI agent over MCP — read a project's status, records, CDE, KPI and model-quality checks; run standards-compliance, schedule-risk, embodied-carbon, permit- readiness and drawing-QA analyses; author the IFC model with GUID-stable recipes; and draft RFIs. Use when the user asks to inspect, analyse, or author a Massing project through Claude.

2026-07-18114

ship-release

ibuilder/massing

The Massing release discipline — how to ship a verified, CI-green version-numbered release direct to main. Invoke whenever finishing a shippable change (feature, fix, doc). Covers version bump (both files), CHANGELOG/roadmap notes, the ruff/lint CI gotchas, tag, push, and CI/CodeQL verification.

2026-07-17114

verify-frontend

ibuilder/massing

How to verify Massing web/viewer UI changes given that the dev-preview geometry loader stalls. Invoke when you changed apps/web and need to prove it works. Covers typecheck/lint/vitest/build, the tools-panel force-build technique, and honest flagging of flows you couldn't exercise.

2026-07-17114

name	backend-tests
description	How to run and add Python tests in the Massing API/data services. Invoke when writing or running backend tests, or debugging a CI test-gate failure. Covers the run_tests.py runner, the manifest guard, per-test env isolation, DB-lock cleanup, and the two idioms (DB-backed vs engine/IFC).

Massing backend tests

There is no pytest. Tests are self-contained test_*.py scripts in services/api/ that spin up their own TestClient, assert, print a one-line summary, and exit non-zero on failure.

Run

cd services/api
PYTHONPATH="src;../data/src" ./.venv/Scripts/python.exe -X utf8 run_tests.py     # whole suite (~40 min)
PYTHONPATH="src;../data/src" ./.venv/Scripts/python.exe -X utf8 test_<name>.py    # one test

Use -X utf8 — some tests print →/²/³ and crash on the default Windows cp1252 console (a false failure; CI uses utf-8).

The manifest guard — REGISTER NEW TESTS

Two test idioms

DB-backed API test: set os.environ["DATABASE_URL"], STORAGE_DIR, and (if it uploads a source IFC) IFC_DIR — all to ./test_*-prefixed local paths (gitignored). os.environ.pop("AEC_RBAC", None). Use TestClient(app) + X-User header. Upload a model via POST /projects/{pid}/source-ifc?publish=false.
Engine/IFC test: prepend ../data/src to sys.path, build a model with aec_data.massing.generate_blank_ifc + aec_data.edit.*, and assert on aec_data/aec_api engine functions directly (no DB needed).

Gotchas

Local DB lock: a killed test can leave test_*.db locked ("Device or resource busy"). Clean rm -f ./test_<name>.db; rm -rf ./test_storage_<name> ./test_ifc_<name> before re-running; if truly stuck, run a throwaway copy with a different db name to verify logic (CI runs clean).
edit_history sidecar: tests that author edits leave state under STORAGE_DIR; clean it between local runs (run_tests.py does this per-test).
Infinite SSE endpoints HANG under TestClient (c.stream + iter_lines never returns). Test the payload/signature logic, not the live stream.
app.routes introspection is unreliable for included-router paths — assert via a real TestClient call instead.
CI ruff runs from services/api with its ruff.toml (isort). See the ship-release skill.

See memory: backend-test-runner, ruff-ci-config-gotcha.