Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:
OpenHWP employs a testing strategy centered on the Deno toolchain to ensure the integrity of its HWP/HWPX viewing and editing capabilities. As the project is currently in its early scaffold stage, the strategy focuses on establishing a baseline of automated checks that contributors must satisfy before code is merged into the main branch.
The strategy encompasses automated linting, formatting, and unit testing, integrated directly into the development workflow and Continuous Integration (CI) pipeline. This ensures that the thin desktop shell and its integration with the rhwp Rust/WASM engine remain stable across supported platforms (macOS, Windows, and Linux).
Sources: CONTRIBUTING.md:23-28, README.en.md:7-12
Core Validation Workflow
The development workflow requires developers to execute a specific suite of Deno-based commands to validate changes. These checks serve as the primary gateway for code quality and functional correctness.
Automated Baseline Checks
The project utilizes the built-in Deno toolchain for all validation tasks. This eliminates the need for external tools like Node.js or Bun.
| Command | Purpose |
|---|---|
deno lint | Analyzes code for potential errors and adherence to coding standards. |
deno fmt --check | Verifies that code adheres to the project's formatting rules. |
deno test | Executes the test suite to verify functional logic. |
Sources: CONTRIBUTING.md:14-16, CONTRIBUTING.md:23-27
Continuous Integration (CI) Gatekeeping
Before a Pull Request can be reviewed or merged, the CI environment must return a "green" status, indicating that all baseline checks have passed.
The diagram above illustrates the sequence of validation steps required from local development to final integration.
Sources: CONTRIBUTING.md:19-21, CONTRIBUTING.md:52-54
Testing Targets and Tools
OpenHWP's testing targets are dictated by its architecture, which separates the platform shell from the document engine.
Deno Runtime Testing
As the project relies on deno desktop, testing is performed against Deno versions ≥ 2.9.0. The test suite executed via deno test is intended to cover the application-level tasks and native bindings once implementation code is fully landed.
Sources: CONTRIBUTING.md:16-17, CONTRIBUTING.md:29-31
Engine Integration Testing
While the rhwp engine (Rust + WebAssembly) is maintained as a separate dependency, OpenHWP's testing includes the integration of WASM packages. This involves:
- @rhwp/core: Testing the parsing and SVG rendering of
.hwpand.hwpxbytes. - @rhwp/editor: Testing the embedding of the editor UI within the desktop shell.
This sequence shows the interaction between the test suite, the shell, and the underlying WASM engine during a rendering test.
Sources: README.en.md:24-34, README.md:28-36
Security and Compliance Validation
Testing is not limited to functional logic but extends to security and community standards.
Vulnerability Management
Security vulnerabilities are handled through a private reporting process rather than public test cases or issues to prevent exploitation. Verified fixes are provided for the latest major version.
Sources: SECURITY.md:5-18
Contribution Standards
The testing strategy includes human-in-the-loop validation for external contributions. Automated systems may close PRs that do not follow the established bug/feature reporting process to ensure that only well-framed, maintainer-approved changes are tested and integrated.
Sources: CONTRIBUTING.md:43-49
Summary of Tools and Environment
The testing environment is strictly controlled to ensure consistency across different developer machines and CI runners.
- Primary Toolchain: Deno (Native)
- Worktree Management: Orca (or similar tools) using
orca.yamlfor environment setup and dependency caching viadeno install. - Version Control: Conventional Commits are required to ensure automated changelog generation remains accurate.
Sources: CONTRIBUTING.md:33-36, orca.yaml:12-19