go-testing
Go testing patterns for Gentleman.Dots, including Bubbletea TUI testing. Trigger: When writing Go tests, using teatest, or adding test coverage.
Best use case
go-testing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Go testing patterns for Gentleman.Dots, including Bubbletea TUI testing. Trigger: When writing Go tests, using teatest, or adding test coverage.
Teams using go-testing should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/go-testing/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How go-testing Compares
| Feature / Agent | go-testing | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Go testing patterns for Gentleman.Dots, including Bubbletea TUI testing. Trigger: When writing Go tests, using teatest, or adding test coverage.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
## 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:
```go
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:
```go
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:
```go
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:
```go
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
```go
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
```go
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
```go
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
```go
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
```bash
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/teatestRelated Skills
skill-registry
Create or update the skill registry for the current project. Scans user skills and project conventions, writes .atl/skill-registry.md, and saves to engram if available. Trigger: When user says "update skills", "skill registry", "actualizar skills", "update registry", or after installing/removing skills.
skill-creator
Creates new AI agent skills following the Agent Skills spec. Trigger: When user asks to create a new skill, add agent instructions, or document patterns for AI.
sdd-verify
Validate that implementation matches specs, design, and tasks. Trigger: When the orchestrator launches you to verify a completed (or partially completed) change.
sdd-tasks
Break down a change into an implementation task checklist. Trigger: When the orchestrator launches you to create or update the task breakdown for a change.
sdd-spec
Write specifications with requirements and scenarios (delta specs for changes). Trigger: When the orchestrator launches you to write or update specs for a change.
sdd-propose
Create a change proposal with intent, scope, and approach. Trigger: When the orchestrator launches you to create or update a proposal for a change.
sdd-init
Initialize Spec-Driven Development context in any project. Detects stack, conventions, testing capabilities, and bootstraps the active persistence backend. Trigger: When user wants to initialize SDD in a project, or says "sdd init", "iniciar sdd", "openspec init".
sdd-explore
Explore and investigate ideas before committing to a change. Trigger: When the orchestrator launches you to think through a feature, investigate the codebase, or clarify requirements.
sdd-design
Create technical design document with architecture decisions and approach. Trigger: When the orchestrator launches you to write or update the technical design for a change.
sdd-archive
Sync delta specs to main specs and archive a completed change. Trigger: When the orchestrator launches you to archive a change after implementation and verification.
sdd-apply
Implement tasks from the change, writing actual code following the specs and design. Trigger: When the orchestrator launches you to implement one or more tasks from a change.
judgment-day
Parallel adversarial review protocol that launches two independent blind judge sub-agents simultaneously to review the same target, synthesizes their findings, applies fixes, and re-judges until both pass or escalates after 2 iterations. Trigger: When user says "judgment day", "judgment-day", "review adversarial", "dual review", "doble review", "juzgar", "que lo juzguen".