Test structure
jssg tests use a simple directory structure where each test case contains two files:- Input files must be named
input.ts
(or appropriate extension) - Expected files must be named
expected.ts
(or appropriate extension) - File extensions should match your target language (
.ts
,.tsx
,.js
,.jsx
)
Command reference
Basic syntax
Language parser to use (e.g., “tsx”, “javascript”, “typescript”).
Path to your transform file (e.g., ”./scripts/codemod.ts”).
Path to test directory (defaults to ”./tests”).
Common options
See all available options in the CLI reference.
Creating effective test cases
1. Start simple:Understanding test results
Exit codes
- 0: All tests passed
- 1: At least one test failed (diffs are printed)
- 2: Error occurred (e.g., syntax error in codemod)
Reading test output
Pro tip: Use
-v
flag for detailed output when debugging test failures.Troubleshooting
Language mismatch
Language mismatch
Problem: Tests fail with parsing errors.
Solution: Ensure the
Solution: Ensure the
-l
flag matches your source files:Files not found
Files not found
Problem: “No test files found” error.
Solution: Check your directory structure and file names:
Solution: Check your directory structure and file names:
Transform not applied
Transform not applied
Problem: Test passes but no changes were made.
Solution: This is normal if your transform returns
Solution: This is normal if your transform returns
null
for unchanged files. If you expect changes:Unexpected diffs
Unexpected diffs
Problem: Test fails with unexpected output.
Solution: Update expected output if changes are intentional:
Solution: Update expected output if changes are intentional:
Codemod syntax errors
Codemod syntax errors
Problem: “Syntax error in codemod” or TypeScript errors.
Solution: Check your transform file:
Solution: Check your transform file:
Workflow integration
Package script
Add to yourpackage.json
:
package.json
CI/CD integration
.github/workflows/test.yml
Best practices
- Start simple: Begin with basic transformations before complex ones
- Test edge cases: Include empty files, files with comments, and malformed code
- Use descriptive names: Make test cases self-documenting
- Keep tests focused: One transformation per test case
- Validate locally: Always test before publishing