본문으로 건너뛰기
cccskills
무료GitHub에 공개

test-writing-discipline

Write and review Handsontable tests that check intended behavior. The skill guides bug reproduction, meaningful assertions, failure diagnosis, and fresh test runs, while covering mock boundaries and migration of broken legacy tests to Playwright.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Use when writing, fixing, or reviewing tests for any Handsontable change (unit, E2E, or wrapper), and whenever a test is red during feature work. Enforces that tests prove intended behavior – not just execute code, and never "green for the sake of green". Covers intent-first (write the test from the requirement, ideally before the code), deciding whether the code or the test is wrong when red (default: the code), the banned ways of faking green, write-the-failing-test-first, verify-with-a-real-run, no hollow assertions, not mocking the unit under test, and migrating broken legacy tests.

연동 도구Playwright
설치 방법 보기

이럴 때 유용합니다

  • Reproducing a bug with a failing test
  • Diagnosing whether code or test expectations are wrong
  • Reviewing assertions for meaningful behavior checks
  • Migrating broken Jasmine tests to Playwright

포함된 파일(1)

  • SKILL.md5.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Test-writing discipline

Correct behavior is the goal, not green. A test that asserts nothing, or asserts the buggy output, certifies the bug. Fix a red test by correcting the code or tightening the test. These rules apply on top of handsontable-playwright-e2e, handsontable-e2e-testing, handsontable-unit-testing.

Intent, not implementation

Write the test from the requirement (what the user or API is supposed to get), ideally before the implementation. For E2E, state the user-observable expectation before wiring a selector.

When a test is red

The code is the prime suspect. Check whether the expectation matches the intended behavior:

  • Expectation correct, code wrong: fix the code, leave the test.
  • Expectation mis-encoded the intent: tighten the test toward the real behavior.
  • Cannot tell: re-read the requirement.

Banned ways of faking green

Reach green only by fixing code or tightening the test. Reject:

  • Deleting or loosening an assertion, or widening a tolerance, to match the output.
  • .skip / xit / xdescribe, or .only / test.only / describe.only / fit / fdescribe (focusing silently drops the rest of the suite).
  • try/catch swallowing a failure.
  • Asserting whatever the code produced (a "snapshot of the bug").
  • it.flaky / retries over a real intermittent failure.

The Stop hook and pre-push run the test you touched and block on red; that forces reconciliation, it does not authorize weakening.

Weakening over an admitted race needs a ticket in the same PR

An assertion weakened or deleted with a race as the reason ("held 15/15 locally", "flakes on classic", "racy on develop") ships only with a filed ticket in the same PR, named beside the change. "Still open, no ticket" is a review blocker (#13332).

"Passes on retry" and "passes in isolation" are not determinism evidence

  • Before calling a test deterministic, run it focused across every leg: cd tests && HOT_E2E_FULL_MATRIX=1 npx playwright test e2e/<spec>.spec.ts --repeat-each 20 (no --project filter, and the variable makes all six theme × bundle legs run it whatever the spec declares; without it only the declared legs run). For a test tagged @cross-browser, repeat it on the engine legs too: npx playwright test --config playwright-engines.config.ts e2e/<spec>.spec.ts --repeat-each 20. The hidden-init migration needed ~700 such runs to expose three rAF-starvation timeouts.
  • A test failing about half the time under that load on unchanged develop reports a product race: file a product ticket and keep the assertion.

Bug fixes: failing test first

  1. Reproduce the bug as a test and watch it fail for the right reason (the missing behavior, not a typo or bad selector).
  2. Apply the fix and watch the same test pass.
  3. On a bugfix PR, name the spec that fails without the fix.

Cover what the change adds

  • Verify a timing-semantics claim against the primitive. setTimeout(0) is the next macrotask, not end-of-task, so a JSDoc saying "closes when the task ends" above it is wrong; that mismatch shipped a data-corruption bug (an editor stranded by alter() committed through stale coordinates, #13332). Read the primitive (setTimeout, queueMicrotask, requestAnimationFrame, a hook's call site) and test what it does.
  • A dedicated X-during-Y path needs a test that drives X during Y. flush, drain, cancel, pending, suspend, a depth counter are the tell. Fire X from inside Y: a hook callback, a nested alter(), an edit inside a batch.
  • Execute every documented form of a new option at least once, the guide's lead form first.

Before saying "done"

  • Run the exact test command fresh, read the full output and exit code, state the result with that evidence. Say so when you did not run it.
  • Banned phrasings: "should work", "this fixes it" without a run, "tested manually, looks fine".
  • After editing source, run the impacted test and confirm green.

No hollow assertions

  • Assert the behavior: expect(getDataAtCell(0, 0)).toBe('x'), not expect(true).toBe(true) and not an it() with no expect at all.
  • Coverage-on-new-code can be satisfied by a line executed without a checked result, so judge quality by the assertion.

Mocking

  • Mock at the real boundary (network, timers, ResizeObserver; see test/__mocks__/), never the unit under test, and mock the complete real data shape.
  • Where a unit test would need to mock a module, write an E2E test.

Broken legacy tests

The Jasmine suite is frozen. Rewrite a broken or flaky legacy *.spec.js as a Playwright test in tests/e2e/ and delete the Jasmine one (no sleep() patches). Routine, low-risk edits to an existing Jasmine spec are fine.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Develop and modify the Handsontable Angular wrapper with guidance on component lifecycle, settings updates, and NgZone, which controls change detection. It also covers standalone examples, global configuration, and the build and test workflow.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Fix settings updates in the Angular wrapper
  • Review change detection around grid operations
  • Update examples to standalone components
handsontable/handsontable2.2만2026년 10월 20일 업데이트

Open local or public web pages in BrowserStack Live for checks on real mobile devices or desktop browsers. The skill prepares temporary access to a local server, launches the requested session, and shares its dashboard link.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Check a local page on an Android device
  • Open a page in Safari on an iPhone or iPad
  • Inspect behavior in a specific desktop browser
handsontable/handsontable2.2만2026년 10월 20일 업데이트

Prepare user-facing changelog entries for source code changes. The skill determines whether an entry is needed, classifies the change, writes a clear title, and uses the project CLI to create a JSON file tied to the pull request.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Add a changelog entry for a bug fix
  • Classify a new feature or behavior change
  • Explain a breaking change and its replacement
handsontable/handsontable2.2만2026년 10월 20일 업데이트

Explore relationships between functions and files using a prebuilt code graph, a map of code dependencies. Trace bugs, inspect callers and execution paths, and assess the impact of refactoring or proposed changes.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Explore callers and dependencies in unfamiliar code
  • Trace a bug across multiple files
  • Assess the impact of renaming or removing code
handsontable/handsontable2.2만2026년 10월 20일 업데이트

Work with Handsontable row and column positions by distinguishing source data, displayed order, and rendered cells. It guides index conversion and helps investigate misplaced data when sorting, filtering, hiding, or moving rows and columns.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Investigating misplaced rows or columns
  • Converting between source and displayed indexes
  • Combining filters with manual column movement
handsontable/handsontable2.2만2026년 10월 20일 업데이트

Create Handsontable documentation examples for JavaScript, TypeScript, React, Angular, and Vue. The skill explains source files, generated JavaScript, required imports and license settings, embedding examples in guides, and checking that each framework version displays correctly.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Adding a code example to a feature guide
  • Preparing examples for multiple frameworks
  • Generating JavaScript examples from TypeScript
handsontable/handsontable2.2만2026년 10월 20일 업데이트

handsontable의 스킬 모두 보기

이 스킬의 문제 신고