skills/go-fuzz-testing/SKILL.md
Automates fuzz test creation for Go projects using Go's native fuzzing engine with consistent software testing patterns. Use when creating fuzz tests, mutation testing, or when the user mentions fuzzing, coverage-guided testing, or property-based testing.
npx skillsauth add sentenz/skills go-fuzz-testingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Instructions for AI coding agents on automating fuzz test creation using consistent software testing patterns in this Go project.
Coverage-Guided Exploration
Go's native fuzzing engine uses code coverage instrumentation to automatically guide input generation toward unexplored code paths, maximizing bug discovery without manual intervention.
Automated Input Generation
Fuzz testing automatically generates random inputs to discover edge cases and unexpected behaviors that manual testing might miss.
Security Vulnerability Discovery
Helps identify security vulnerabilities, crashes, and undefined behaviors by testing with malformed, unexpected, or extreme inputs.
Continuous Testing
Fuzz tests can run continuously to explore the input space over time, discovering new edge cases as the corpus grows.
Regression Prevention
Once a crash or bug is found, the input is saved in the corpus to prevent regression in future test runs.
The FIRST principles for fuzz testing focus on creating effective and discoverable tests.
Fast
Fuzz tests should use efficient seed corpus and focused fuzz targets to maximize coverage discovery within practical time constraints during CI.
Independent
Each fuzz test should be self-contained and test a single function or behavior independently from other fuzz tests.
Repeatable
Fuzz tests with a fixed corpus should produce deterministic results, ensuring that discovered crashes are reproducible and regression corpus inputs are stable.
Self-Validating
Fuzz tests should clearly detect and report panics, invariant violations, and unexpected behaviors without requiring manual inspection.
Timely
Fuzz tests should be introduced alongside unit tests for functions that accept external inputs or perform calculations with boundary conditions.
Coverage-Guided Fuzzing is the primary fuzzing technique used by Go's native fuzzing engine. It automatically instruments code to track coverage and guides input generation toward unexplored code paths, maximizing code exploration and bug discovery.
Corpus-Driven Fuzzing is a software testing technique that uses a collection of seed inputs (corpus) as the starting point for generating new test inputs through mutation.
Property-Based Testing is a testing approach that verifies invariants and properties that should hold true for all inputs, rather than testing specific input-output pairs.
Boundary Value Fuzzing focuses on testing edge cases and boundary conditions with randomly generated inputs around critical thresholds.
Crash Detection is the process of identifying inputs that cause panics, runtime errors, or undefined behavior in the code under test.
Identify
Identify functions in pkg/ or internal/ that accept external inputs, perform calculations, or have edge cases worth fuzzing (e.g., pkg/<package>/<file>.go).
Add/Create
Create fuzz tests in the same package (e.g., pkg/<package>/<file>_test.go).
Fuzz Test Coverage Requirements
Focus on functions that:
Apply Templates
Structure all fuzz tests using the template pattern.
Seed Corpus
Optionally provide seed inputs in testdata/fuzz/<FuzzTestName>/ directory to guide fuzzing toward interesting inputs.
| Command | Description |
| -------------------------------------- | -------------------------------------------- |
| make go-test-fuzz | Execute fuzz tests for a specified duration |
| ls -la testdata/fuzz/<FuzzTestName>/ | Inspect the seed corpus and generated inputs |
Test Framework
Use the standard Go
testingpackage withtesting.Ffor fuzz tests. Go's fuzzing engine automatically uses coverage-guided fuzzing to explore code paths.
Coverage-Guided Behavior
The fuzzing engine tracks code coverage during execution and prioritizes inputs that explore new code paths. No manual configuration is required - coverage guidance is automatic.
Include Imports
Include
testingand any packages needed for the function under test.
Fuzz Function Naming
Name fuzz functions with the
Fuzzprefix followed by the function name (e.g.,FuzzPercentfor testingPercent()).
Seed Corpus
Use
f.Add()to provide seed inputs that cover important edge cases and known valid/invalid inputs. The fuzzer will mutate these seeds while maximizing coverage.
Fuzz Target
The fuzz target function receives
*testing.Tand randomly generated inputs. It should:
- Validate inputs before calling the function under test (skip invalid inputs with
t.Skip()if necessary)- Call the function with fuzzed inputs
- Assert invariants and properties that must always hold true
- Not crash or panic for any input
Error Handling
Fuzz tests should verify that functions handle errors gracefully without panicking.
Assertions
Use explicit checks with
t.Errorf()ort.Fatalf()to report violations of expected properties.
Use this template for new fuzz test functions. Replace placeholders with actual values and adjust as needed for the use case.
For functions with multiple parameters, use a struct array to define test cases.
func Fuzz<FunctionName>(f *testing.F) {
// Seed corpus with edge cases using testcases array
testcases := []struct {
param1 <type>
param2 <type>
// Add more parameters as needed
}{
{<value1>, <value2>}, // description of test case
{<value1>, <value2>}, // description of test case
// Add more test cases
}
for _, tc := range testcases {
f.Add(tc.param1, tc.param2) // Use f.Add to provide a seed corpus
}
f.Fuzz(func(t *testing.T, param1 <type>, param2 <type>) {
// Arrange
// Optional: skip invalid inputs or prepare test conditions
// Example: if input < 0 { t.Skip("negative inputs not interesting") }
// Act
got, err := <Function>(param1, param2)
// Assert
// Verify properties that should always hold true
// Example 1: Function should never panic
// Example 2: If no error, result should meet certain properties
// Example 3: If error, result should be in expected error state
if err != nil {
// Verify error cases
// Example: if got != 0 { t.Errorf("expected zero result on error, got %v", got) }
} else {
// Verify success cases and invariants
// Example: if got < 0 { t.Errorf("result should be non-negative, got %v", got) }
}
})
}
For functions with a single parameter, use a slice array to define test cases.
func Fuzz<FunctionName>(f *testing.F) {
// Seed corpus with edge cases using testcases array
testcases := []<type>{
<value1>, // description
<value2>, // description
// Add more test cases
}
for _, tc := range testcases {
f.Add(tc) // Use f.Add to provide a seed corpus
}
f.Fuzz(func(t *testing.T, param <type>) {
// Arrange
// Optional: skip invalid inputs or prepare test conditions
// Act
got, err := <Function>(param)
// Assert
// Verify properties and invariants
if err != nil {
// Verify error cases
} else {
// Verify success cases
}
})
}
development
Creates and maintains Architecture Decision Records (ADRs) following a structured format with State, Context, Decision, Considered, Consequences, Implementation, and References sections. Supports single-option decisions, multi-option decisions within one decision scope, multiple complementary decisions, and deferred decisions. Use when creating, updating, or reviewing architectural decisions, or when the user mentions ADR, architecture decisions, technical decisions, or design records.
tools
Performs end-to-end threat modeling for OT/ICS systems from Microsoft Threat Modeling Tool (TMT) threat-list exports (`*.csv`) and model files (`*.tm7`). Uses TMT and STRIDE for initial threat enumeration, then enriches each threat with OT/ICS context, MITRE ATT&CK for ICS mappings, MITRE EMB3D device-property threat enrichment for embedded field devices, CWE weakness classification, CVSS v4.0 scoring, Likelihood of Exploit, Risk-based Prioritization via a Risk Matrix, minimum-capable Threat Actor assignment, Risk Treatment decisions, and OT impact categories ranging from Denial of View to Physical Damage to Property.
development
Automates unit test creation for Go projects using the standard testing package with consistent software testing patterns including In-Got-Want, Table-Driven Testing, and AAA patterns. Use when creating, modifying, or reviewing unit tests, or when the user mentions unit tests, test coverage, or Go testing.
development
Automates benchmark test creation for Go projects using the standard testing package with consistent software testing patterns. Use when creating performance benchmarks, profiling tests, or when the user mentions benchmarking, performance testing, or optimization.