c-testing
/c-testing
Opisuje proces testów jednostkowych i integracyjnych w C: deterministyczne uprzęże, CMake i CTest, debugowanie z sanitizerami oraz fuzzing.
- Autor
- aeondave ↗
- Repozytorium
- malskill ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 13.11.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 5
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 13.11.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Opisuje proces testów jednostkowych i integracyjnych w C: deterministyczne uprzęże, CMake i CTest, debugowanie z sanitizerami oraz fuzzing.
Oryginalny opis (EN)
C testing workflow for unit and integration tests: deterministic harnesses, CMake/CTest execution strategy, sanitizer-first debugging, and fuzzing escalation. Use when writing or fixing tests for C (C11+) modules, stabilizing flaky suites, or reproducing memory/UB bugs.
Jak działa
- When to activate
- Core rules
- Recommended workflow
- Fast triage checklist
- Resources
Podgląd SKILL.md
--- name: c-testing description: "C testing workflow for unit and integration tests: deterministic harnesses, CMake/CTest execution strategy, sanitizer-first debugging, and fuzzing escalation. Use when writing or fixing tests for C (C11+) modules, stabilizing flaky suites, or reproducing memory/UB bugs." license: MIT compatibility: "C11 baseline. Tools: CMake/CTest or Make. Debugging: gdb/lldb (Linux/macOS), MinGW gdb + objdump (Windows), MSVC dumpbin + WinDbg (Windows). Optional: sanitizers (Clang/GCC), fuzzing (libFuzzer/AFL where supported)." metadata: author: AeonDave version: "1.1" --- # C Testing Pragmatic workflow for reliable C tests and bug-finding. ## When to activate - Adding unit tests for C functions - Building a small test harness around a module - Debugging failing tests or memory corruption - Enabling sanitizers or fuzzing to reproduce crashes --- ## Core rules - Keep unit tests deterministic and isolated. - Avoid real network/time in unit tests. - Run ASan/UBSan in CI for memory and UB signal. - Reproduce failures in the smallest possible command first. - Do not hide memory/UB bugs behind test-only flags, retries, or inflated timeouts. - Pair with `test-driven-development` when implementing persistent code or bug fixes test-first. - Pair with `testing-reliability` for fixture/timing anti-patterns and `systematic-debugging` when the root cause is unclear. --- ## Recommended workflow ### Phase 1 — Reproduce with smallest scope - Run the single failing test first (`ctest -R ...` or direct binary invocation). - Capture exact command, seed/input, and environment variables. - Eliminate unrelated test noise before debugging. ### Phase 2 — Strengthen harness determinism - Keep each test independent (no shared mutable global state). - Use explicit fixtures/setup-teardown for temp files and state reset. - Prefer table-driven tests for parsers and boundary-heavy functions. ### Phase 3 — Sanitizer-first diagnosis - Run AddressSanitizer for memory corruption/UAF/OOB. - Run UndefinedBehaviorSanitizer for integer/shift/null/alignment UB. - Use stack-symbolized reports before stepping into debugger. ### Phase 4 — CTest execution strategy - Label tests (`unit`, `integration`, `slow`, `flaky`) and run by label. - Use `--output-on-failure` and `--rerun-failed` in local loops. - Add per-test `TIMEOUT` to avoid hanging pipelines. ### Phase 5 — Fuzzing escalation - Add libFuzzer target for parser/decoder/validator style APIs. - Seed corpus with valid and invalid minimal inputs. - Keep fuzz target stateless, deterministic, and side-effect free. --- ## Fast triage checklist - [ ] Single failing test reproduced in isolation. - [ ] Failure reproduced under sanitizer build (if memory/UB suspected). - [ ] Backtrace/symbolization points to root cause function. - [ ] Regression test added for the fixed bug. - [ ] Full suite rerun (or label-targeted suite if justified) with no new failures. --- ## Resources Load on demand: - `references/harness.md` — harness structure, assertions, Unity/cmocka options - `references/cmake-ctest.md` — CMake/CTest patterns, labels, sanitizer presets, MinGW cross-compile - `references/sanitizers-fuzzing.md` — ASan/UBSan usage and a minimal fuzz target outline - `references/debugging.md` — gdb/lldb, Valgrind, MinGW objdump/nm, MSVC dumpbin/WinDbg, ASan env vars
Pliki w paczce (5)
- SKILL.md 3 KB
- references/cmake-ctest.md 3 KB
- references/debugging.md 3 KB
- references/harness.md 3 KB
- references/sanitizers-fuzzing.md 2 KB
Wersje
W bazie nie ma innych skilli o nazwie c-testing.
Migawka bazy z 13.11.2026 · wersja paczki 53003b22cdf8 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 90cpp-testing
Prowadzi testy jednostkowe i integracyjne C++ z GoogleTest, CMake i CTest, diagnozując niestabilne testy i sanitizery. - 100testing-strategy
Opisuje metodykę testów: piramidę, deterministyczne testy jednostkowe i integracyjne oraz diagnozę niestabilnych testów. - 90cmake-guide
Podpowiada przy edycji plików CMake w projektach C i C++: dodawanie celów, linkowanie, FetchContent i testy CTest. - 96cpp-testing
Pomaga pisać, naprawiać i diagnozować testy C++, konfigurować GoogleTest i CTest oraz mierzyć pokrycie. - 100testing
Stosuje dobre praktyki testów jednostkowych, integracyjnych i E2E przy pisaniu testów, przeglądzie pokrycia i projektowaniu kodu. - 95testing-builder
Generuje zestawy testów jednostkowych, integracyjnych i E2E na podstawie kodu i dotychczasowych wzorców testowania, także jako testy regresji po naprawie błędów.