quality-assurance

Guides test design for Flix game projects with assertion and mocking conventions.

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/ababup1192/flix_ge_studio --skill quality-assurance-ababup1192
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: quality-assurance
Source: https://github.com/ababup1192/flix_ge_studio/tree/main/.agents/skills/quality-assurance
Command: npx skills add https://github.com/ababup1192/flix_ge_studio --skill quality-assurance-ababup1192

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests for Flix game projects often leads to brittle, low-value tests: hardcoded numbers that break on balance tuning, multiple assertions per test, duplicated mocks, and tests that merely restate the code. This Skill provides a complete test design policy so every @Test is meaningful, maintainable, and consistent. ## Core Features & Use Cases - Test Scope Rules: Defines exactly what to test (game rules, progression, JSON/Doc bridging) and what not to test (motion, coordinates, trivial getters). - Doc-Derived Expectations: Requires expected values to be derived from Doc (JSON defaults) instead of pasted numeric literals, so balance changes never break tests. - Structural Conventions: Enforces one assertion per test (tuple packing), bug! for unreachable match branches, effect-polymorphic mock helpers, and round-number test data. - Use Case: When you create a new Scene module or edit Game.flix logic, apply this Skill to write a test file that verifies state transitions and boundary conditions with clean, readable assertions. ## Quick Start Ask the AI to write tests for a new Flix module following the quality-assurance test design guidelines.

Frequently Asked Questions about quality-assurance

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write tests for Flix game logic?▼

Test only game rules, progression, and JSON Doc bridging, using the module's public API and constructors rather than hand-built internal state. Write one assertion per test, packing multiple values into a tuple for a single assertEq call.

How do I mock side effects in Flix tests?▼

Use effect-polymorphic helper functions with signatures like Unit -> a \ ef + Effect so other effects pass through transparently. Place shared mocks in an aggregate test file and reuse them instead of writing run-with-handler blocks directly in test bodies.

What should I not test in a game project?▼

Do not test motion, display timing, coordinate transcription, or trivial getter/setter identity, since visual regressions belong to snapshot comparison and manual review. Click hit detection counts as a rule and should remain tested.

How do I keep tests from breaking when game balance changes?▼

Derive expected values from Doc JSON defaults through expressions like Prologue.dayLen(d()) instead of pasting numeric literals. This way balance tuning in JSON files never breaks the test suite.

How do I compare floating point values in Flix tests?▼

Use assertEq for deterministic values, but for computations with rounding error like normalization or trigonometry, use assertTrue with Float64.abs(actual - expected) < epsilon. Choose epsilon by meaning, such as 0.001 for positions.

How many JSON bridging tests should each Doc have?▼

Limit each Doc to at most three bridging tests: broken JSON falling back to defaults, a single-field override being reflected, and variable-length rows being followed. Exhaustive decoder validation belongs in the shared JsonCodec layer once.