nim-testing
Skill4 starsChanged 3 months agoMITView on GitHub
Write and run deterministic Nim tests, including isolated test files, expected-exception checks, multi-configuration builds, and sanitizer integration. Use when setting up a Nim test suite, testing failure behavior, running tests across debug/release/danger modes, or adding AddressSanitizer support.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- planetis-m/skillsword for word, first seen Jul 16, 2026
Other versions1 project uses a version of this.
Word for word · 1
- planetis-m/skills★ 59100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- atlas-package-clonerSkill
- buildSkill
- docs-genSkill
- format-codeSkill
- nim-api-designSkill
- nim-c-bindingsSkill
- nim-code-organizationSkill
- nim-c-wrappersSkill
- nim-debuggingSkill
- nim-defect-analysisSkill
- nim-doc-commentsSkill
- nim-error-handlingSkill
- nim-fuzzingSkill
- nim-mcp-toolsSkill
- nimonypluginsSkill
- nim-ownership-hooksSkill
- nim-style-guideSkill
- run-testsSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 2 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Import std/assertions. Use block scopes with doAssert and doAssertRaises:
- Very specific: line 32
Use ordinary call syntax and grouped negation inside doAssert:
- Very specific: line 44
Avoid command-call syntax in assertions.
- Very specific: line 61
Test files use t prefix: tbasic.nim, tedge.nim, terrors.nim, tintegration.nim.
- Very specific: line 93
Run from project root: nim c -r tests/tester.nim
- Distinctive: line 99
Keep test files self-contained when practical.
- Very specific: line 103
Set up layout: Create src/, tests/, and tests/config.nims.
- Very specific: line 105
Create the runner: Add tests/tester.nim with the auto-discover pattern.
- Distinctive: line 114
Run with ASan: if the project uses unsafe constructs.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Nim Testing
Rules
Use block-based tests with doAssert
Import std/assertions. Use block scopes with doAssert and doAssertRaises:
import std/assertions
block add_basic:
doAssert add(1, 2) == 3, "add should sum positive integers"
block greet_empty:
doAssert greet("") == "hello "
block parse_bad_input:
doAssertRaises ValueError:
discard parseThing("")doAssert raises AssertionDefect on failure. doAssertRaises passes only when the requested exception type is raised; otherwise the test exits non-zero.
Write unambiguous assertions
Use ordinary call syntax and grouped negation inside doAssert:
proc foo(x: int): int = x
proc same(x, y: int): bool = x == y
doAssert foo(1) == 1, "foo should return its argument"
doAssert same(1, 1), "same values should match"
doAssert not (foo(1) < 0), "foo should not return a negative value"
doAssert 4 notin @[1, 2, 3]Avoid command-call syntax in assertions. doAssert foo 1 == 1 can bind the
comparison to foo, and doAssert same 1, 1 can bind the comma to doAssert.
Project layout
project/
src/
mylib.nim
tests/
config.nims # shared compiler switches
tester.nim # central test runner (auto-discovers t*.nim)
tbasic.nim
tedge.nim
terrors.nimTest files use t prefix: tbasic.nim, tedge.nim, terrors.nim, tintegration.nim.
tests/config.nims
switch("path", "$projectdir/../src")The compiler loads this config automatically when compiling files in tests/.
tests/tester.nim
import std/os
proc fatal(msg: string) = quit "FAILURE " & msg
proc exec(cmd: string) =
echo "Running: ", cmd
if execShellCmd(cmd) != 0: fatal cmd
let testDir = getCurrentDir() / "tests"
for f in walkFiles(testDir / "t*.nim"):
let name = f.extractFilename
if name == "tester.nim":
discard
else:
exec "nim c -r " & quoteShell(testDir / name)
echo "All test files completed."Run from project root: nim c -r tests/tester.nim
New test files are auto-discovered — no runner edits needed.
Shared Test Code
Keep test files self-contained when practical. If setup is repeated, extract domain helpers such as sample builders, temp-file setup, or fixture data.
Workflow
- Set up layout. Create
src/,tests/, andtests/config.nims. - Write test files. Name files with
tprefix. Useblock,doAssert, anddoAssertRaises. - Create the runner. Add
tests/tester.nimwith the auto-discover pattern. Run all configurations:
nim c -r tests/tester.nim nim c -d:release -r tests/tester.nim nim c -d:danger -r tests/tester.nim- Run with ASan if the project uses unsafe constructs. See "AddressSanitizer" below.
- Set up CI. See
references/ci_github_actions.md.
Multi-configuration testing
| Mode | Overflow checks | Stack traces (file:line) |
default / -d:debug | Yes | Full |
-d:release | Yes | Raising frame only |
-d:danger | No | Raising frame only |
- Overflow checks: Disabled in danger. Use
when defined(danger)guards. - Stack traces: Release and danger show only the raising frame. Add
--lineTrace:onto restore full traces with line numbers. assert: Compiled out in danger. UsedoAssert.
AddressSanitizer
nim c \
--passC:"-fsanitize=address -fno-omit-frame-pointer" \
--passL:"-fsanitize=address -fno-omit-frame-pointer" \
-g -d:noSignalHandler -d:useMalloc \
-r tests/tester.nim--passC/--passL: Both required.-g: Embeds debug info for Nim source locations in reports.-d:noSignalHandler: Lets ASan report directly instead of Nim's signal handler.-d:useMalloc: Uses C'smallocso ASan tracks every allocation.
Windows (MSVC): nim c --cc:vcc --passC:"/fsanitize=address" -r tests/tester.nim
Sanitizer config in tests/config.nims
switch("path", "$projectdir/../src")
when defined(addressSanitizer):
switch("debugger", "native")
switch("define", "noSignalHandler")
switch("define", "useMalloc")
when defined(windows):
switch("passC", "/fsanitize=address")
else:
switch("passC", "-fsanitize=address -fno-omit-frame-pointer")
switch("passL", "-fsanitize=address -fno-omit-frame-pointer")Then: nim c -d:addressSanitizer -r tests/tester.nim
Common Mistakes
| Mistake | Why it is wrong |
Using assert instead of doAssert | assert is compiled out in danger. Use doAssert. |
Relying on OverflowDefect without when defined(danger) | Never raised in danger mode. |
Running ASan without -d:useMalloc | Nim's default allocator is not intercepted by ASan. |
Running ASan without -d:noSignalHandler | Nim's signal handler intercepts SIGSEGV before ASan reports. |
Using only --passC without --passL for ASan | The sanitizer runtime must be linked. |
Writing doAssert foo 1 == 1 | Nim parses it like doAssert foo(1 == 1). Use doAssert foo(1) == 1. |
References
references/block_test_pattern.md— An isolated test layout with block tests, runner, and commands.references/ci_github_actions.md— Cross-platform GitHub Actions CI with Linux ASan.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

