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.