chore: improve test run speed

[ymc9]

Summary by CodeRabbit

• New Features
  • Introduced a new test setup process to improve testing efficiency.
  • Enhanced zenstack generate commands with additional options for better control.
• Bug Fixes
  • Improved error handling during command execution in the schema tool.
• Chores
  • Updated .gitignore to exclude .test directories.
  • Refined test configuration for better coverage and performance.
  • Simplified project setup by automating file copying from scaffold directory.
• Refactor
  • Clarified variable names and updated comments for better readability in the schema tool.
• Tests
  • Modified integration test settings to align with new testing strategies.

[coderabbitai]

Important

Auto Review Skipped

Review was skipped due to path filters

Files ignored due to path filters (2)

• package.json is excluded by: !**/*.json
• pnpm-lock.yaml is excluded by: !**/*.yaml

Walkthrough

The updates involve refining the project's configuration and testing setup. Changes include enhancing .gitignore, modifying Jest configuration for better path handling and simplifying by inheriting base settings, and adjusting the schema tool's error handling and command execution. A new setup file for global test configuration introduces a structured approach to initializing test environments. These adjustments aim at streamlining development workflows, improving clarity, and ensuring a more robust and maintainable codebase.

Changes

File(s)	Change Summary
.gitignore	Added .test to ignored directories.
jest.config.ts	Streamlined by importing base config, adjusting paths with path.join, and setting globalSetup.
.../testtools/src/schema.ts	Improved error handling, clarity in variable naming, and updated command execution.
test-setup.ts	Introduced for setting up test environments, including directory creation and dependency management.
.../tests/schema/todo.zmodel	Commented out preserveTsFiles in the plugin zod section.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository from git and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 4398231 and a635436.

Files ignored due to path filters (2)

• packages/testtools/package.json is excluded by: !**/*.json
• packages/testtools/src/package.template.json is excluded by: !**/*.json

Files selected for processing (6)

• .gitignore (1 hunks)
• jest.config.ts (1 hunks)
• packages/testtools/src/schema.ts (4 hunks)
• test-setup.ts (1 hunks)
• tests/integration/jest.config.ts (1 hunks)
• tests/integration/tests/schema/todo.zmodel (1 hunks)

Files skipped from review due to trivial changes (1)

• .gitignore

Additional comments: 11

tests/integration/jest.config.ts (2)

• 1-1: Importing a base configuration from ../../jest.config is a good practice for maintaining consistency across different Jest configurations in the project. This approach helps in centralizing common configurations and reducing duplication.
• 8-8: The addition of setupFilesAfterEnv: ['./test-setup.ts'] specifies a setup file to be executed after the test environment is set up but before the tests are run. This is a good practice for configuring or setting up testing frameworks that cannot be configured in the Jest configuration directly.

jest.config.ts (3)

• 6-6: The addition of import path from 'path'; is necessary for using path.join in the configuration. This is a good practice for handling file paths in a platform-independent manner.
• 12-12: Adding a globalSetup configuration with a path to test-setup.ts is a good practice. It allows executing a setup script before any of the tests are run, which can be used for setting up a test environment or performing global initializations.
• 18-18: Using path.join(__dirname, '.test/coverage') for the coverageDirectory ensures that the coverage output directory is correctly resolved relative to the current file's directory. This is a more robust approach than hardcoding paths.

test-setup.ts (1)

• 1-39: The test-setup.ts file introduces a comprehensive setup process for test scaffolding, including creating a scaffold directory, running initialization commands, and installing dependencies. This setup is crucial for ensuring a consistent and isolated environment for tests. The use of path.join for path handling, fs.existsSync and fs.rmSync for directory cleanup, and execSync for command execution are all appropriate choices for these tasks. Additionally, handling local dependencies installation is a good practice for testing in a monorepo setup or when local packages are involved. Overall, this setup script is well-structured and follows good practices for test environment preparation.

tests/integration/tests/schema/todo.zmodel (1)

• 17-17: Commenting out preserveTsFiles = true in the plugin zod section may affect how TypeScript files are handled during testing, potentially leading to faster test execution by not preserving TypeScript files. It's important to ensure that this change aligns with the project's testing requirements and does not negatively impact the ability to debug tests or the accuracy of type checking.

packages/testtools/src/schema.ts (4)

• 38-50: Adding a try-catch block around the execSync command execution in the run function is a good practice for error handling. It ensures that any errors during command execution are caught and logged, providing better feedback and preventing unhandled exceptions.
• 146-148: Renaming the variable from root to workspaceRoot for clarity is a good practice. It makes the code more readable and understandable, especially in the context of monorepos or projects with complex directory structures.
• 155-157: The addition of a file copy operation from the scaffold directory to the project root is a good practice for setting up a consistent test environment. It ensures that the necessary project structure and files are in place before running tests or generating schemas.
• 197-203: Modifying the zenstack generate commands to include additional options and specifying NODE_PATH improves the flexibility and correctness of schema generation. It allows for more precise control over the generation process and ensures that dependencies are correctly resolved.

[coderabbitai]

Review Status

Actionable comments generated: 5

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between a635436 and 5e2807b.

Files ignored due to path filters (1)

• package.json is excluded by: !**/*.json

Files selected for processing (7)

• .github/workflows/build-test.yml (1 hunks)
• CONTRIBUTING.md (1 hunks)
• packages/testtools/src/schema.ts (5 hunks)
• script/test-scaffold.ts (1 hunks)
• test-setup.ts (1 hunks)
• tests/integration/tests/cli/generate.test.ts (2 hunks)
• tests/integration/tests/cli/plugins.test.ts (2 hunks)

Files skipped from review as they are similar to previous changes (1)

• test-setup.ts

Additional comments: 8

script/test-scaffold.ts (3)

• 5-9: Creating the scaffold directory is done without checking if it already exists, which is efficient due to the use of fs.existsSync followed by fs.rmSync and fs.mkdirSync. This ensures the directory is fresh for each test run.
• 11-18: The run function correctly executes shell commands within the scaffoldPath directory and handles errors by logging them and re-throwing. This is a good practice for error handling in scripts, ensuring that errors do not go unnoticed.
• 21-22: The use of npm i --no-audit --no-fund flags during package installation is a good practice for speeding up npm installs in a CI/CD environment by skipping unnecessary checks.

.github/workflows/build-test.yml (1)

• 100-100: Adding pnpm run test-scaffold before pnpm run test-ci in the CI workflow is a logical step to ensure that the test scaffold is set up before running the main test suite. This change aligns with the PR's objective to improve test run speed by optimizing setup processes.

CONTRIBUTING.md (1)

• 38-44: The addition of instructions for running pnpm test-scaffold in the contribution guide is clear and provides necessary guidance for contributors to set up the project for testing. Mentioning that this command only needs to be run once is helpful for avoiding confusion.

tests/integration/tests/cli/generate.test.ts (1)

• 46-47: Replacing direct execSync calls with installPackage for installing packages is a good practice. It abstracts the complexity of package installation, potentially handling edge cases and errors more gracefully. This change contributes to making the test setup more maintainable and readable.

tests/integration/tests/cli/plugins.test.ts (1)

• 97-98: Using installPackage instead of direct npm commands for installing dependencies in CLI Plugins Tests is an improvement. It standardizes the installation process and potentially provides better error handling and logging. This change enhances the maintainability and readability of the test setup.

packages/testtools/src/schema.ts (1)

• 150-152: Changing the variable name from root to workspaceRoot improves clarity and readability, making it easier to understand the purpose of the variable. This change aligns with best practices for naming conventions.