CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/unity-test-framework-c

Author and run ThrowTheSwitch Unity (the C unit-testing library) for bare-metal and RTOS C code. Distinct from the Unity game-engine Test Framework at docs.unity3d.com: this is the ThrowTheSwitch C testing library at throwtheswitch.org/unity, a single C file plus headers that runs on 8-bit MCUs through 64-bit hosts. Anchored on the Unity assertion API and configuration macros regardless of execution environment: the TEST_ASSERT_EQUAL_* / _FLOAT / _DOUBLE / _STRING / _MEMORY / _BITS assertion families, setUp/tearDown/RUN_TEST/UNITY_BEGIN/UNITY_END semantics and the exit-code contract, the generate_test_runner.rb generator, build-time config defines (UNITY_INCLUDE_DOUBLE, UNITY_OUTPUT_CHAR, UNITY_EXCLUDE_SETJMP), and CI integration via Ceedling JUnit XML; applies to host builds, cross-builds, and QEMU-run targets alike. For QEMU machine flags, semihosting, and exit-code capture, see qemu-system-test-runner. Use when the unit-under-test is pure C and the target ranges from 8-bit AVR to Cortex-M0 to Linux ARM.

74

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a well-structured, highly executable reference: complete code for authoring, host and cross builds, output parsing, and CI, with detail properly offloaded to two real one-level-deep reference files. The main deductions are minor redundancy in the Overview/References (conciseness) and the absence of an explicit fix-and-retry validation loop within the build/run workflow itself.

Suggestions

Collapse the Overview's game-engine disambiguation to a single sentence or a pointer to the description, since the frontmatter already carries the full distinction — this is the main conciseness drag.

Drop the References section's re-listing of inline citations and keep only the sibling-skill pointers, removing the duplication between "Cited inline" entries and the body's links.

Add an explicit validation checkpoint in the Running section (e.g., after running the binary: expect the "2 Tests 0 Failures" summary; if any ":FAIL:" line appears, fix the code or assertion and re-run) so the build/run loop has its own fix-and-retry step instead of relying solely on the later Parsing gate.

DimensionReasoningScore

Conciseness

The body is largely lean and code-forward ("Minimal test", host/cross build commands, anti-patterns table) with no explanation of basics Claude already knows, but the Overview repeats the game-engine disambiguation already carried in the frontmatter ("It is distinct from the Unity game-engine Test Framework ... The two share only a name") and the References section re-lists citations already given inline. This matches the 4 anchor ("Efficient; minor instances of over-explanation that could be trimmed") rather than 5 ("every token earns its place").

4 / 5

Actionability

Everything is executable and copy-paste ready: a complete minimal test file with setUp/tearDown/main, "gcc -Wall -O0 -g -DUNITY_INCLUDE_DOUBLE ... -o test_ringbuffer", the arm-none-eabi-gcc + qemu-system-arm cross-build pair, the runner-generation command "ruby /path/to/Unity/auto/generate_test_runner.rb ...", and the "grep -c ':FAIL:'" smoke gate. This matches the 5 anchor ("copy-paste ready code or commands; specific examples cover the common cases") rather than 4, since host, cross, and CI cases are all covered with runnable commands.

5 / 5

Workflow Clarity

The document is sequenced Authoring → Building → Running → Parsing → CI, and the shown expected console output ("2 Tests 0 Failures 0 Ignored / OK") plus the "[ "$fails" -eq 0 ] || exit 1" grep gate serve as checkpoints. However there is no explicit validate-fix-retry loop after the build/QEMU steps (the gate lives only in the Parsing section), matching the 4 anchor ("clear sequence with most checkpoints present; minor validation gaps") rather than 5 ("explicit validation steps; feedback loops for error recovery"). The workflow_clarity cap of 3 does not apply since this is not a destructive or batch operation.

4 / 5

Progressive Disclosure

Bulk detail is correctly split into real, clearly signaled, one-level-deep references: "The full assertion-family table and the build-time config defines are in [references/assertion-api.md](references/assertion-api.md)" and "The standalone (no Ceedling) GitHub Actions pipeline ... is in [references/ci-integration.md](references/ci-integration.md)". Both files exist, contain exactly the promised content, and point no deeper; the inline body keeps only key examples. This matches the 5 anchor ("Clear overview with well-signaled one-level-deep references; content appropriately split") rather than 4, whose "minor organization gaps" are absent.

5 / 5

Total

18

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is explicit and dense with concrete API, tooling, and target specifics, includes a clear 'Use when ...' trigger clause, and proactively disambiguates itself from the similarly-named Unity game-engine Test Framework. Its only notable weakness is length — the exhaustive macro-family enumeration is body-level detail — but that padding does not weaken any scored dimension against the anchors.

DimensionReasoningScore

Specificity

Quotes: "Author and run ThrowTheSwitch Unity ... for bare-metal and RTOS C code", "the generate_test_runner.rb generator", "build-time config defines (UNITY_INCLUDE_DOUBLE, UNITY_OUTPUT_CHAR, UNITY_EXCLUDE_SETJMP)", "CI integration via Ceedling JUnit XML". Concrete actions span authoring, running, configuration, and CI with no coverage gaps — a clear match to the 5 anchor ("multiple specific concrete actions; comprehensive coverage"), not 4, which requires minor gaps that are absent here.

5 / 5

Completeness

Explicitly answers both: what — "Author and run ThrowTheSwitch Unity (the C unit-testing library) ... the TEST_ASSERT_EQUAL_* ... assertion families, setUp/tearDown/RUN_TEST/UNITY_BEGIN/UNITY_END semantics and the exit-code contract" — and when — "Use when the unit-under-test is pure C and the target ranges from 8-bit AVR to Cortex-M0 to Linux ARM". This is the 5 anchor ("clearly and explicitly answers both what AND when with concrete trigger phrases"); the 4-anchor caveat ("'when' could be more explicit") does not apply since the trigger clause is explicit and concrete.

5 / 5

Trigger Term Quality

Quotes: "unit-testing", "pure C", "bare-metal", "RTOS", "8-bit AVR", "Cortex-M0", "Linux ARM", "QEMU-run targets", "Ceedling". These are the natural phrases an embedded developer would actually say when needing this skill, covering synonyms and target-family variations; matches the 5 anchor ("comprehensive coverage of natural terms including synonyms") rather than 4 ("a few natural terms missing").

5 / 5

Distinctiveness Conflict Risk

Quotes: "Distinct from the Unity game-engine Test Framework at docs.unity3d.com: this is the ThrowTheSwitch C testing library at throwtheswitch.org/unity". It proactively defuses the single most likely wrong-skill collision (the name "Unity") and the trigger ("unit-under-test is pure C") carves a clear niche with minimal conflict risk — the 5 anchor, not 4 ("minor overlap risk with closely related skills").

5 / 5

Total

20

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 3 missing

Warning

Total

15

/

16

Passed

Reviewed

Table of Contents