Run any Skill in Manus with one click

walkontable-testing

Stars1

Forks0

UpdatedJuly 8, 2026 at 07:31

Use when writing tests for the Walkontable rendering engine - has its own separate test pipeline, runner, and configuration distinct from main Handsontable E2E tests

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Stars1233

Stars1233/handsontable

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

More from this repository

same repository

handsontable-dev

Stars1233/handsontable

Use for ANY work touching the `handsontable/` core package: fixing bugs, adding features, modifying TypeScript types, removing as-casts, writing or debugging plugins, editors, renderers, validators, cell types, hooks, shortcuts, selection, helpers, index translations, or i18n. Also use for how-to questions about core internals (plugin lifecycle, coordinate systems, hook registration, TypeScript conventions). Triggers on file paths under `handsontable/src/` (excluding `3rdparty/walkontable/` which has its own skill), or when the user describes a symptom in the core grid without naming a file. This is the primary entry point for all core Handsontable development — when in doubt, load it.

2026-06-241

handsontable-e2e-testing

Stars1233/handsontable

Use when writing or modifying Jasmine/Puppeteer E2E tests (*.spec.js) for Handsontable, or when a bug fix or feature change needs E2E test coverage. Covers standard boilerplate, async/await rules, global helpers, event simulation, plugin lifecycle patterns, and writing theme-agnostic assertions that pass under all themes without branching on theme name.

2026-06-161

handsontable-unit-testing

Stars1233/handsontable

Use when writing or modifying Jest unit tests (*.unit.js) or TypeScript type tests (*.types.ts) for Handsontable core, plugins, or utilities, or when a bug fix or internal refactor needs unit or type test coverage - covers Jest setup, test location conventions, mocking patterns, module aliases, type test patterns (no declare, real assignments, ESM + UMD patterns), and when to choose unit tests over E2E tests

2026-06-031

name	walkontable-testing
path	handsontable/src/3rdparty/walkontable/**
description	Use when writing tests for the Walkontable rendering engine - has its own separate test pipeline, runner, and configuration distinct from main Handsontable E2E tests

Testing the Walkontable Rendering Engine

Separate Test Pipeline

Walkontable has its own dedicated test runner. Do NOT run Walkontable tests through the main test:e2e or test:unit commands -- they will not be picked up.

Run command: npm run test:walkontable --prefix handsontable
Test location: src/3rdparty/walkontable/test/

The directory contains two sub-pipelines:

test/spec/ -- E2E-style specs (Jasmine + Puppeteer, same as main E2E but with a separate Rspack config and bootstrap)
test/unit/ -- Unit-style specs for calculators, filters, renderers, and utilities

Writing Tests

The same async/await rules that apply to main E2E tests apply here. All it() callbacks that call rendering APIs must be async, and those API calls must be await-ed.

Tests are organized by subsystem: overlay/, scroll/, selection/, renderer/, table/, viewport.spec.js, etc. Place new tests in the directory that matches the subsystem you are modifying.

What to Cover

Frozen rows and columns: The overlay system (6 overlay types) is the most fragile part of Walkontable. Always include tests with frozen rows/columns to catch overlay positioning and synchronization regressions.
Viewport calculations: Test with various container sizes (small containers that clip content, containers larger than the data, and containers that resize dynamically).
Scroll synchronization: Verify that scrolling the main table keeps frozen overlays aligned. Test both horizontal and vertical scroll.
Large datasets: Include performance-oriented tests with 10k+ rows. Use forEach loops to populate data arrays -- never arr.push(...largeArray).

Common Mistakes

Running Walkontable tests via test:e2e -- they have their own command and will not execute.
Skipping frozen row/column scenarios -- this misses the overlay edge cases where most regressions occur.
Testing only small datasets -- Walkontable bugs often surface at scale.
Modifying Walkontable test bootstrap/Rspack config without verifying that both spec/ and unit/ sub-pipelines still pass.
Turning on the uniform-size flags (rowHeightsUniform/columnWidthsUniform) in a bare Walkontable spec and then asserting scrollbar-dependent row/column counts: the bare harness overflows content without rendering a real scrollbar, while the single-pass layout snapshot predicts one — so predicted and measured diverge there. Assert the snapshot booleans directly, or use a fixture that renders a real scrollbar; don't compare snapshot-predicted scrollbars/counts against the bare DOM.