Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

backend-tests

Estrelas114

Forks56

Atualizado17 de julho de 2026 às 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).

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

ibuilder

ibuilder/massing

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.