/golang-testing
Write unit tests with table-driven patterns and interface mocking in Go. Use when writing Go unit tests, table-driven tests, or using mock interfaces.
$ npx -y skills add hoangnguyen0403/agent-skills-standard --skill golang-testing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/golang-testing
Context preview
The summary Claude sees to decide when to auto-load this skill.
Write unit tests with table-driven patterns and interface mocking in Go. Use when writing Go unit tests, table-driven tests, or using mock interfaces.
SKILL.md
golang-testing.SKILL.mdname: golang-testing
description: Write unit tests with table-driven patterns and interface mocking in Go. Use when writing Go unit tests, table-driven tests, or using mock interfaces.
metadata:
triggers:
files:
- '**/*_test.go'
keywords:
- testing
- unit tests
- go test
- mocking
- testifyGolang Testing
**Priority: P0 (CRITICAL)**
Implementation Workflow
1. **Write failing test first** — Follow Red-Green-Refactor TDD workflow. 2. **Use table-driven tests** — Define test cases as slice of structs; iterate with `t.Run()`. 3. **Mock via interfaces** — Use DI and interfaces. Prefer `mockery` for auto-generated mocks or manual mocks for simple cases. 4. **Run parallel** — Use `t.Parallel()` for non-sequential tests to speed up CI. 5. **Clean up resources** — Use `t.Cleanup()` to restore state or release DB/file resources. 6. **Check coverage** — Aim for >80% line coverage. Run `go test -cover` to audit.
See [table-driven test examples](references/table-driven-tests.md)
Tools
- **Stdlib**: `testing` package usually enough.
- **Testify**: Assertions (`assert`, `require`) and mocks.
- **Mockery**: Auto-generate mocks for interfaces.
- **GoMock**: Popular mocking framework alternative.
Naming
- Test file: `*_test.go`
- Test function: `func TestName(t *testing.T)`
- Example function: `func ExampleName()`
Anti-Patterns
- **No assert in loops**: use `t.Run` subtests to isolate failures.
- **No global mock state**: define mocks locally within test scope.
- **No skipping race detection**: always run `go test -race` in CI.
References
- [Table-Driven Tests](references/table-driven-tests.md)
- [Mocking Strategies](references/mocking-strategies.md)
Read more
name: golang-testing
description: Write unit tests with table-driven patterns and interface mocking in Go. Use when writing Go unit tests, table-driven tests, or using mock interfaces.
metadata:
triggers:
files:
- '**/*_test.go'
keywords:
- testing
- unit tests
- go test
- mocking
- testifyGolang Testing
**Priority: P0 (CRITICAL)**
Implementation Workflow
1. **Write failing test first** — Follow Red-Green-Refactor TDD workflow. 2. **Use table-driven tests** — Define test cases as slice of structs; iterate with `t.Run()`. 3. **Mock via interfaces** — Use DI and interfaces. Prefer `mockery` for auto-generated mocks or manual mocks for simple cases. 4. **Run parallel** — Use `t.Parallel()` for non-sequential tests to speed up CI. 5. **Clean up resources** — Use `t.Cleanup()` to restore state or release DB/file resources. 6. **Check coverage** — Aim for >80% line coverage. Run `go test -cover` to audit.
See [table-driven test examples](references/table-driven-tests.md)
Tools
- **Stdlib**: `testing` package usually enough.
- **Testify**: Assertions (`assert`, `require`) and mocks.
- **Mockery**: Auto-generate mocks for interfaces.
- **GoMock**: Popular mocking framework alternative.
Naming
- Test file: `*_test.go`
- Test function: `func TestName(t *testing.T)`
- Example function: `func ExampleName()`
Anti-Patterns
- **No assert in loops**: use `t.Run` subtests to isolate failures.
- **No global mock state**: define mocks locally within test scope.
- **No skipping race detection**: always run `go test -race` in CI.
References
- [Table-Driven Tests](references/table-driven-tests.md)
- [Mocking Strategies](references/mocking-strategies.md)
The portable SDLC standards layer for AI coding agents. Sync once, then work in your own runtime.
Repo: hoangnguyen0403/agent-skills-standard
Other skills on agent-skills-standard.
- /android-agp-upgrade
Upgrade an Android project to Android Gradle Plugin (AGP) 9. Use when migrating to AGP 9, updating Gradle build files, migrating to built-in Kotlin, or adopting the new AGP DSL.
Open skill - /android-architecture
Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow
Open skill - /android-background-work
Implement WorkManager and background processing correctly on Android. Use when creating Worker classes, scheduling tasks, choosing between WorkManager and Foreground Services, or setting up Hilt in workers; defer FCM and notification delivery to android-notifications.
Open skill - /android-compose-migration
Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.
Open skill - /android-compose
Build high-performance declarative UI with Jetpack Compose. Use when writing Composable functions, optimizing recomposition, hoisting state, or working with LazyColumn and side effects; defer deep-link and navigation routing to android-navigation.
Open skill - /android-concurrency
Write correct coroutine scopes, lifecycle collection, and dispatcher injection in Android production code. Use for suspend functions, coroutine scopes, and dispatcher mechanics; defer ViewModel StateFlow/LiveData architecture, Fragment lifecycle recipes,
Open skill

