Validation And Testing
Morph package work should be validated as aggressively as compiler core work.
What To Validate
For a package change, validate at least:
- manifest parsing
- feature discovery
- package graph resolution
- runtime or backend ownership if the feature uses them
- command/build/execution wiring when applicable
Typical Test Layers
| Layer | Example Questions |
|---|---|
| Docs/shape | does the package layout follow the contract? |
| Loader | do manifests and imports resolve? |
| Semantic | does the feature mean what the package claims? |
| Lowering | does it lower through package-owned paths? |
| Runtime | are runtime families and runtime behavior wired correctly? |
| Tooling/build | do commands and providers resolve without core edits? |
Boundary Tests Matter
Morph work often needs boundary tests, not only behavior tests.
Examples:
- a feature should not reintroduce core ownership
- a runtime family should stay package-owned
- a build provider should not require a core switch branch
These tests protect the architecture, not just the output.
Validate The Negative Cases
Do not test only the success path.
Also test:
- missing imports
- duplicate identifiers
- unresolved runtime family requirements
- unsupported provider or artifact combinations
- missing generated glue or registration failures
Documentation Is Part Of Validation
For Morph work, docs are part of the contract too.
If package behavior changes, package documentation and author guidance should stay aligned so future contributors do not drift back into core-first habits.
Next Steps
- Plugin-governed pipeline - manifests, providers/routes, and package registration model
- Generated Glue And Factories - where codegen + plugin registration lives in this repo
- Migration And Anti-Patterns - common failure modes when packages grow
- Ternary Condition Case Study - applying validation thinking to a concrete feature