القائمة
Testing best practices for Go projects including table-driven tests, mocking, and test organization. Use this when writing or reviewing test code.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use this skill whenever writing, reviewing, or refactoring ANY Go code — even small snippets. Triggers on: Go functions, structs, interfaces, goroutines, error handling, package design, HTTP handlers, CLI tools, or any .go file task. Don't skip this for 'simple' Go requests; idiomatic style matters even in small examples.
Remove defensive checks and silent fallbacks that only fire when upstream is broken
Commit staged files only, generate message/PR, push to new branch
Enforce Go logging best practices for CLI tools, especially those doing high-volume file operations (read, write, parse, modify, scaffold). Use this skill whenever the user is writing, reviewing, or debugging Go CLI logging code — even if they only mention "how do I log this" or "add logging to my tool." Triggers on: slog, log/slog, zerolog, zap, logrus, --verbose flag, debug flag, file operation logging, structured logging, log levels, CLI output, scaffold tool, or any Go CLI that reads/writes/parses files. Always apply this skill before suggesting any logging approach in Go CLI context — don't rely on training data alone, the patterns here are authoritative for idiomatic Go 1.21+.
Best practices for building Go CLI applications using cobra and viper. Use this when creating new commands, handling flags, or implementing CLI workflows.
Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.
| name | go-testing |
| description | Testing best practices for Go projects including table-driven tests, mocking, and test organization. Use this when writing or reviewing test code. |
Use table-driven tests for functions with multiple scenarios:
func TestValidateProjectName(t *testing.T) {
tests := []struct {
name string
input string
wantErr bool
}{
{
name: "valid project name",
input: "my-terraform-project",
wantErr: false,
},
{
name: "empty project name",
input: "",
wantErr: true,
},
{
name: "invalid characters",
input: "my_project@123",
wantErr: true,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
err := ValidateProjectName(tt.input)
if tt.wantErr {
assert.Error(t, err)
} else {
assert.NoError(t, err)
}
})
}
}
// In pkg/structure/filesystem.go
type FileSystem interface {
MkdirAll(path string, perm os.FileMode) error
WriteFile(filename string, data []byte, perm os.FileMode) error
}
// Production implementation
type OSFileSystem struct{}
func (fs *OSFileSystem) MkdirAll(path string, perm os.FileMode) error {
return os.MkdirAll(path, perm)
}
// Test mock
type MockFileSystem struct {
mock.Mock
}
func (m *MockFileSystem) MkdirAll(path string, perm os.FileMode) error {
args := m.Called(path, perm)
return args.Error(0)
}
package testutil
func CreateTempDir(t *testing.T) string {
t.Helper()
dir, err := os.MkdirTemp("", "tfskel-test-*")
require.NoError(t, err)
t.Cleanup(func() { os.RemoveAll(dir) })
return dir
}