go-testing
A set of Go testing patterns and best practices, specifically for table-driven tests and TUI component validation.
Install
mkdir -p .claude/skills/go-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4209" && unzip -o skill.zip -d .claude/skills/go-testing && rm skill.zipInstalls to .claude/skills/go-testing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Go testing patterns for Gentleman.Dots, including Bubbletea TUI testing. Trigger: When writing Go tests, using teatest, or adding test coverage.Key capabilities
- →Implement table-driven test patterns
- →Simulate TUI model state transitions
- →Execute interactive flows with teatest
- →Verify TUI model updates
How it works
Applies boilerplate testing structures and test-model primitives to simulate user input and state changes within the Go testing runtime.
Inputs & outputs
When to use go-testing
- →Write table-driven unit tests
- →Test Bubbletea TUI models
- →Increase test coverage
- →Create integration tests
About this skill
When to Use
Use this skill when:
- Writing Go unit tests
- Testing Bubbletea TUI components
- Creating table-driven tests
- Adding integration tests
- Using golden file testing
Critical Patterns
Pattern 1: Table-Driven Tests
Standard Go pattern for multiple test cases:
func TestSomething(t *testing.T) {
tests := []struct {
name string
input string
expected string
wantErr bool
}{
{
name: "valid input",
input: "hello",
expected: "HELLO",
wantErr: false,
},
{
name: "empty input",
input: "",
expected: "",
wantErr: true,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
result, err := ProcessInput(tt.input)
if (err != nil) != tt.wantErr {
t.Errorf("error = %v, wantErr %v", err, tt.wantErr)
return
}
if result != tt.expected {
t.Errorf("got %q, want %q", result, tt.expected)
}
})
}
}
Pattern 2: Bubbletea Model Testing
Test Model state transitions directly:
func TestModelUpdate(t *testing.T) {
m := NewModel()
// Simulate key press
newModel, _ := m.Update(tea.KeyMsg{Type: tea.KeyEnter})
m = newModel.(Model)
if m.Screen != ScreenMainMenu {
t.Errorf("expected ScreenMainMenu, got %v", m.Screen)
}
}
Pattern 3: Teatest Integration Tests
Use Charmbracelet's teatest for TUI testing:
func TestInteractiveFlow(t *testing.T) {
m := NewModel()
tm := teatest.NewTestModel(t, m)
// Send keys
tm.Send(tea.KeyMsg{Type: tea.KeyEnter})
tm.Send(tea.KeyMsg{Type: tea.KeyDown})
tm.Send(tea.KeyMsg{Type: tea.KeyEnter})
// Wait for model to update
tm.WaitFinished(t, teatest.WithDuration(time.Second))
// Get final model
finalModel := tm.FinalModel(t).(Model)
if finalModel.Screen != ExpectedScreen {
t.Errorf("wrong screen: got %v", finalModel.Screen)
}
}
Pattern 4: Golden File Testing
Compare output against saved "golden" files:
func TestOSSelectGolden(t *testing.T) {
m := NewModel()
m.Screen = ScreenOSSelect
m.Width = 80
m.Height = 24
output := m.View()
golden := filepath.Join("testdata", "TestOSSelectGolden.golden")
if *update {
os.WriteFile(golden, []byte(output), 0644)
}
expected, _ := os.ReadFile(golden)
if output != string(expected) {
t.Errorf("output doesn't match golden file")
}
}
Decision Tree
Testing a function?
├── Pure function? → Table-driven test
├── Has side effects? → Mock dependencies
├── Returns error? → Test both success and error cases
└── Complex logic? → Break into smaller testable units
Testing TUI component?
├── State change? → Test Model.Update() directly
├── Full flow? → Use teatest.NewTestModel()
├── Visual output? → Use golden file testing
└── Key handling? → Send tea.KeyMsg
Testing system/exec?
├── Mock os/exec? → Use interface + mock
├── Real commands? → Integration test with --short skip
└── File operations? → Use t.TempDir()
Code Examples
Example 1: Testing Key Navigation
func TestCursorNavigation(t *testing.T) {
tests := []struct {
name string
startPos int
key string
endPos int
numOptions int
}{
{"down from 0", 0, "j", 1, 5},
{"up from 1", 1, "k", 0, 5},
{"down at bottom", 4, "j", 4, 5}, // stays at bottom
{"up at top", 0, "k", 0, 5}, // stays at top
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
m := NewModel()
m.Cursor = tt.startPos
// Set up options...
newModel, _ := m.Update(tea.KeyMsg{
Type: tea.KeyRunes,
Runes: []rune(tt.key),
})
m = newModel.(Model)
if m.Cursor != tt.endPos {
t.Errorf("cursor = %d, want %d", m.Cursor, tt.endPos)
}
})
}
}
Example 2: Testing Screen Transitions
func TestScreenTransitions(t *testing.T) {
tests := []struct {
name string
startScreen Screen
action tea.Msg
expectScreen Screen
}{
{
name: "welcome to main menu",
startScreen: ScreenWelcome,
action: tea.KeyMsg{Type: tea.KeyEnter},
expectScreen: ScreenMainMenu,
},
{
name: "escape from OS select",
startScreen: ScreenOSSelect,
action: tea.KeyMsg{Type: tea.KeyEsc},
expectScreen: ScreenMainMenu,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
m := NewModel()
m.Screen = tt.startScreen
newModel, _ := m.Update(tt.action)
m = newModel.(Model)
if m.Screen != tt.expectScreen {
t.Errorf("screen = %v, want %v", m.Screen, tt.expectScreen)
}
})
}
}
Example 3: Testing Trainer Exercises
func TestExerciseValidation(t *testing.T) {
exercise := &Exercise{
Solutions: []string{"w", "W", "e"},
Optimal: "w",
}
tests := []struct {
input string
valid bool
optimal bool
}{
{"w", true, true},
{"W", true, false},
{"e", true, false},
{"x", false, false},
}
for _, tt := range tests {
t.Run(tt.input, func(t *testing.T) {
valid := ValidateAnswer(exercise, tt.input)
optimal := IsOptimalAnswer(exercise, tt.input)
if valid != tt.valid {
t.Errorf("valid = %v, want %v", valid, tt.valid)
}
if optimal != tt.optimal {
t.Errorf("optimal = %v, want %v", optimal, tt.optimal)
}
})
}
}
Example 4: Mocking System Info
func TestWithMockedSystem(t *testing.T) {
m := NewModel()
// Mock system info for testing
m.SystemInfo = &system.SystemInfo{
OS: system.OSMac,
IsARM: true,
HasBrew: true,
HomeDir: t.TempDir(),
}
// Now test with controlled environment
m.SetupInstallSteps()
// Verify expected steps
hasHomebrew := false
for _, step := range m.Steps {
if step.ID == "homebrew" {
hasHomebrew = true
}
}
if hasHomebrew {
t.Error("should not have homebrew step when HasBrew=true")
}
}
Test File Organization
installer/internal/tui/
├── model.go
├── model_test.go # Model tests
├── update.go
├── update_test.go # Update handler tests
├── view.go
├── view_test.go # View rendering tests
├── teatest_test.go # Teatest integration tests
├── comprehensive_test.go # Full flow tests
├── testdata/
│ ├── TestOSSelectGolden.golden
│ └── TestViewGolden.golden
└── trainer/
├── types.go
├── types_test.go
├── exercises.go
├── exercises_test.go
└── simulator_test.go
Commands
go test ./... # Run all tests
go test -v ./internal/tui/... # Verbose TUI tests
go test -run TestNavigation # Run specific test
go test -cover ./... # With coverage
go test -update ./... # Update golden files
go test -short ./... # Skip integration tests
Resources
- TUI Tests: See
installer/internal/tui/*_test.go - Trainer Tests: See
installer/internal/tui/trainer/*_test.go - System Tests: See
installer/internal/system/*_test.go - Golden Files: See
installer/internal/tui/testdata/ - Teatest Docs: https://github.com/charmbracelet/bubbletea/tree/master/teatest
When not to use it
- →When testing non-Go projects
- →When the application does not rely on Bubbletea UI
Prerequisites
Limitations
- →Requires familiarity with Bubbletea architecture
- →Testing interactive flows can be brittle to UI changes
How it compares
Uses domain-specific patterns for TUI and table-driven testing that go beyond basic Go unit test templates.
Compared to similar skills
go-testing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| go-testing (this skill) | 1 | 7mo | Review | Intermediate |
| vitest | 41 | 6mo | No flags | Intermediate |
| svelte-expert | 11 | 9mo | No flags | Intermediate |
| implementing-cards | 7 | 2mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Gentleman-Programming
View all by Gentleman-Programming →You might also like
vitest
antfu
Vitest fast unit testing framework powered by Vite with Jest-compatible API. Use when writing tests, mocking, configuring coverage, or working with test filtering and fixtures.
svelte-expert
Raudbjorn
Expert Svelte/SvelteKit development assistant for building components, utilities, and applications. Use when creating Svelte components, SvelteKit applications, implementing reactive patterns, handling state management, working with stores, transitions, animations, or any Svelte/SvelteKit development task. Includes comprehensive documentation access, code validation with svelte-autofixer, and playground link generation.
implementing-cards
bcollazo
Fill out the implementation of effects of different attacks, abilities, and trainer cards in this Pokemon TCG Pocket engine codebase.
zod-4
prowler-cloud
Zod 4 schema validation patterns. Trigger: When creating or updating Zod v4 schemas for validation/parsing (forms, request payloads, adapters), including v3 -> v4 migration patterns.
csharp-pro
sickn33
Write modern C# code with advanced features like records, pattern matching, and async/await. Optimizes .NET applications, implements enterprise patterns, and ensures comprehensive testing. Use PROACTIVELY for C# refactoring, performance optimization, or complex .NET solutions.
write-unit-tests
tldraw
Writing unit and integration tests for the tldraw SDK. Use when creating new tests, adding test coverage, or fixing failing tests in packages/editor or packages/tldraw. Covers Vitest patterns, TestEditor usage, and test file organization.