Summary
Restructure the test corpus so language behavior is grouped by execution stage instead of keeping everything in one flat bucket.
Why
Right now tests mostly validate output or error text, which is already useful. But as the language grows, we should be explicit about whether a program is expected to:
- run successfully
- fail in parsing
- fail in semantic analysis
- fail at runtime
That makes the language behavior clearer and prevents vague “some error happened” coverage.
Proposed changes
Acceptance criteria
- Test cases are grouped by category
- Harness supports category-aware assertions
- Existing tests are migrated without behavior loss
- Adding new tests in each category is straightforward
Notes
This is mainly a test-organization/specification issue, not a language-feature issue.
Summary
Restructure the test corpus so language behavior is grouped by execution stage instead of keeping everything in one flat bucket.
Why
Right now tests mostly validate output or error text, which is already useful. But as the language grows, we should be explicit about whether a program is expected to:
That makes the language behavior clearer and prevents vague “some error happened” coverage.
Proposed changes
Split test cases into categories:
success/syntax_error/semantic_error/runtime_error/Update the test harness to:
Acceptance criteria
Notes
This is mainly a test-organization/specification issue, not a language-feature issue.