Testing Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• test-startup-optimization.js
• test-tutorial-disable.html
• scripts/build-all.js
• scripts/deploy.js
• src/data-validator.js
• build-errors/error-1763198715230.json
• src/main.js

The testing strategy for skid-inc is a pragmatic approach combining automated scripts for build and deployment, runtime data validation, and specific feature tests. This strategy ensures the stability of the application from the build pipeline to the end-user experience, with a strong emphasis on release integrity and save data consistency. The project does not use a formal testing framework but relies on a series of Node.js scripts, HTML-based tests, and integrated validation modules.

This approach can be broken down into three main areas: build and deployment testing, runtime data integrity checks, and feature-specific test scripts.

Build and Deployment Integrity

Testing is integrated directly into the build and deployment pipeline to ensure that only valid and verified artifacts are released. This is managed by two key scripts: build-all.js and deploy.js.

Automated Build Validation

The scripts/build-all.js script automates the application build process for Windows, macOS, and Linux. It incorporates several testing and validation steps to ensure a reliable build.

Key Features:

• Environment Validation: Before starting a build, the validateEnvironment function checks for the existence of package.json, the availability of electron-builder, and the presence of required source files like src/main.js and index.html.
• Error Handling and Retries: The build process for each platform includes retry logic. If a build fails, it is automatically retried up to a configured maximum (maxRetries), with a delay between attempts.
• Timeout Monitoring: Each platform build is subject to a timeout (timeout) to prevent hangs.
• Reporting: Upon completion, a build-report.json is generated in the output directory, containing metrics on duration, success, failures, and a list of generated artifacts.

Sources: scripts/build-all.js:75-100, 126-179, 182-201

The following diagram illustrates the automated build flow.

Release Artifact Verification

The scripts/deploy.js script is responsible for packaging release artifacts and ensuring their integrity. It performs checksum generation for all distributable files.

Key Features:

• Artifact Collection: Gathers distributable files from the build output directory.
• Checksum Generation: Calculates a sha256 hash for each artifact. These checksums are saved in a central checksums.txt file and also as individual .sha256 files. This allows for integrity verification after download.
• Manifest Creation: Generates a manifest.json file containing metadata about the release, including file sizes and their checksums.

The diagram below shows the deployment process with a focus on artifact verification.

Runtime Data Validation

Runtime testing focuses on maintaining the integrity of the game's save data. This is primarily handled by the DataValidator class.

Sources: src/data-validator.js

Game State Schema

The DataValidator uses a predefined schema (gameStateSchema) to validate the structure, types, and constraints of the game state object before it's saved and after it's loaded. This schema defines required fields, default values, and constraints like minimum/maximum values.

A snippet of the player schema is shown below:

// from src/data-validator.js:12-25
player: {
    type: 'object',
    required: true,
    properties: {
      username: { type: 'string', required: false, default: 'Player' },
      money: { type: 'number', required: true, default: 0, min: 0 },
      totalMoney: { type: 'number', required: true, default: 0, min: 0 },
      exp: { type: 'number', required: true, default: 0, min: 0 },
      totalExp: { type: 'number', required: true, default: 0, min: 0 },
      expReq: { type: 'number', required: true, default: 100, min: 1 },
      level: { type: 'number', required: true, default: 1, min: 1 },
      botnet: { type: 'number', required: false, default: 0, min: 0 },
      prestigeCount: { type: 'number', required: false, default: 0, min: 0 }
    }
}

Sources: src/data-validator.js:12-25

In addition to schema validation, the main process in src/main.js performs a basic validateGameState check to ensure critical properties exist before attempting a save.

Sources: src/main.js:688-709

Validation and Repair Flow

When validateGameState is called, it recursively traverses the game state object. If it finds discrepancies (e.g., wrong type, missing required field, value out of bounds), it attempts to repair the data automatically.

Repair mechanisms include:

• Setting missing fields to their default values.
• Converting data to the correct type (e.g., a number stored as a string).
• Clamping numerical values to their defined min and max constraints.
• Truncating strings that exceed maxLength.

This ensures that the save files remain consistent and reduces the risk of corruption or crashes due to malformed data.

The flow of data validation and repair is as follows:

Feature-Specific Test Scripts

The repository contains standalone test files for verifying specific functionalities.

Startup Optimization Test

The test-startup-optimization.js script is an integration test for the StartupOptimizer module. It verifies that the application's startup sequence is performant and that caching mechanisms are working correctly.

The test performs the following checks:

1. Optimized Startup: Runs startOptimizedStartup and logs the total time, comparing it to a target.
2. Metadata Caching: Checks if caching is enabled and logs the cache size.
3. Performance Score: Retrieves and logs the calculated startup score.
4. Cache Operations: Runs a maintenance cycle on the cache.
5. Configuration Update: Tests the ability to update the optimizer's configuration at runtime.

The sequence diagram below shows the interactions during the test.

Tutorial Disabling Test

The test-tutorial-disable.html file provides a simple, isolated environment to test the logic for disabling the game's tutorial. This is critical for ensuring that players with existing save files are not shown the intro sequence again.

The test works by:

1. Simulating the skidinc game object and its tutorial module.
2. Providing a function ensureTutorialCompleted() that mimics the state change after a save is loaded. This function sets tutorial flags, hides the intro UI (.intro), and shows the main game UI (.game).
3. A "Test Tutorial Disable" button triggers this function and logs the results, asserting that the UI state has changed correctly.

The state changes tested in this file can be visualized as follows:

Build Failure Analysis

The project maintains logs of build errors, such as build-errors/error-1763198715230.json. These JSON files serve as a crucial tool for debugging the CI/CD pipeline. They capture a snapshot of the system state and the error context at the time of failure.

A typical error log contains the following information:

Key	Description
timestamp	The UTC timestamp of when the error occurred.
version	The project version being built.
error	A concise error message, usually from the failed command.
stack	The JavaScript stack trace leading to the error.
buildLog	A detailed, chronological log of all commands and their outputs during the build process.

Sources: build-errors/error-1763198715230.json

Analyzing this log, the root cause of the failure was Cannot find module 'C:\\Users\\alpha\\skid-inc\\node build\\prebuild.js'. This indicates an incorrect path was being resolved by electron-builder when trying to execute a pre-build script, providing a clear starting point for debugging the build configuration.

Sources: build-errors/error-1763198715230.json:28-30