بنقرة واحدة
testing-golang
Goテストの作成・修正・設計で使用。並行処理テスト、モック、テーブル駆動テストを扱う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Goテストの作成・修正・設計で使用。並行処理テスト、モック、テーブル駆動テストを扱う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
1Password CLI (op) でサインイン・vault 確認・secret 注入を行う時に使う。Claude セッションでは service account token (OP_SERVICE_ACCOUNT_TOKEN) をtoken ファイル (~/.config/op/service-account-token) から直前注入する方式を使い、op read の stdout を Claude context に流さない方針を強制する。「op signin」「op service-account」「op read」「op run」「op inject」「1Password から取って」などで発火。
Browser automation for opening sites, forms, clicks, screenshots, scraping, login, and web app testing.
Run browser automation on AWS Bedrock AgentCore cloud browsers or AWS-hosted sessions.
Capture architecture decisions as ADRs with context, alternatives, and rationale.
不具合修正のワークフロー(調査→再現→修正→検証)を controller がオーケストレーションするための指揮書。バグ・不具合・障害の修正で使う。explorer で原因特定、implementer で再現テスト→修正、verifier で検証。「バグを直して」「不具合修正」「この障害を調査して直す」などで参照。
Create CodeTour `.tour` walkthroughs with file/line anchors.
| name | testing-golang |
| description | Goテストの作成・修正・設計で使用。並行処理テスト、モック、テーブル駆動テストを扱う。 |
| invocation | auto |
| ecc-imports | [{"upstream-commit":"4e66b2882da9afb9747468b08a253ca2f09c85f3","upstream-path":"skills/golang-testing/SKILL.md","sections-merged":[],"conflicts":["When to Activate","TDD Workflow for Go","Table-Driven Tests","Subtests and Sub-benchmarks","Test Helpers","Golden Files","Mocking with Interfaces","Benchmarks","Fuzzing (Go 1.18+)","Test Coverage","HTTP Handler Testing","Testing Commands","Best Practices","Integration with CI/CD"],"imported-at":"2026-04-26T15:00:00.000Z"}] |
| 項目 | バージョン |
|---|---|
| Go | 1.21+ |
| testify | v1.9+ |
| mockery | v2.x |
| testcontainers-go | v0.30+ |
Goのユニットテスト作成を支援するスキル。testifyフレームワークを使用したテーブル駆動テストと、testcontainersを活用した統合テスト、mockeryを使用したモック生成をサポートする。プロジェクト固有の規約に従い、包括的で保守性の高いテストコードを提供する。
ライブラリの最新ドキュメントが必要な場合は、Context7 MCPツールを使用すること。
# 例: testify の最新ドキュメントを取得
1. resolve-library-id で "stretchr/testify" を検索
2. query-docs でライブラリIDを使って必要な情報を取得
| 項目 | 規約 | 備考 |
|---|---|---|
| ファイル命名 | xxx_test.go 形式 | Go標準 |
| ファイル比率 | プロダクトコード1ファイルに対してテストコード1ファイル | 推奨 |
| テストフレームワーク | testify を使用(assert、require、mock) | Go標準的 |
| テストパターン | テーブル駆動テストを基本 | Go標準的 |
| モック生成 | mockery を使用 | 推奨 |
| 統合テスト | testcontainers を使用 | 推奨 |
外部テスト + ドットインポートを推奨:
package mypackage_test
import (
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
. "your-project/internal/mypackage" // ドットインポート
)
func TestPublicFunction(t *testing.T) {
result := PublicFunction("test")
assert.Equal(t, "expected", result)
}
ブラックボックステストでありながら、パッケージ名プレフィックスなしで直接呼び出せるため可読性が高い。
func TestFunctionName(t *testing.T) {
tests := []struct {
name string
input InputType
want ExpectedType
wantErr bool
}{
{
name: "success: basic case",
input: validInput,
want: expectedOutput,
wantErr: false,
},
{
name: "error: invalid input",
input: invalidInput,
want: zeroValue,
wantErr: true,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := FunctionName(tt.input)
if tt.wantErr {
require.Error(t, err)
return
}
require.NoError(t, err)
assert.Equal(t, tt.want, got)
})
}
}
tests := []struct {
name string
}{
{name: "success: description"}, // 正常な動作
{name: "error: description"}, // エラーケース
{name: "edge case: description"}, // 境界値や特殊ケース
}
| メソッド | 用途 | 失敗時の動作 |
|---|---|---|
require | 前提条件のチェック | テストを即座に中断 |
assert | 複数のアサーション | テストを継続 |
// require: エラーの場合、テストを即座に終了
require.NoError(t, err)
require.NotNil(t, result)
// assert: エラーでもテストを継続
assert.Equal(t, expected, actual)
assert.True(t, condition)
// 等価性
assert.Equal(t, expected, actual)
assert.NotEqual(t, expected, actual)
// nil チェック
assert.Nil(t, object)
assert.NotNil(t, object)
// エラーチェック
assert.NoError(t, err)
assert.Error(t, err)
assert.EqualError(t, err, "expected error message")
assert.ErrorIs(t, err, targetErr) // errors.Is を使用
// ブール値
assert.True(t, condition)
assert.False(t, condition)
// コンテナ
assert.Contains(t, slice, element)
assert.Len(t, collection, expectedLength)
assert.Empty(t, collection)
モックの作成には mockery + testify/mock の組み合わせを使用する。詳細は references/mock-patterns.md を参照。
# インターフェースからモックを生成
mockery --name=UserRepository --output=mocks --outpkg=mocks
package mypackage_test
import (
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/mock"
"your-project/mocks"
)
func TestUserService_GetUser(t *testing.T) {
// モックの作成
mockRepo := mocks.NewMockUserRepository(t)
// 期待する呼び出しを設定
mockRepo.EXPECT().
GetByID(mock.Anything, int64(1)).
Return(&User{ID: 1, Name: "Test"}, nil).
Once()
// テスト対象の作成
service := NewUserService(mockRepo)
// テスト実行
user, err := service.GetUser(context.Background(), 1)
// アサーション
assert.NoError(t, err)
assert.Equal(t, "Test", user.Name)
}
詳細なモックパターンは references/mock-patterns.md を参照。
テストを作成する際は、以下のエッジケースを必ず考慮すること。詳細は references/edge-cases.md を参照。
データベースや外部サービスとの統合テストには、testcontainersを使用する。詳細は references/testcontainers-patterns.md を参照。
func TestDatabaseOperation(t *testing.T) {
db, cleanup := setupPostgresContainer(t)
defer cleanup()
// テスト実行...
}
ファズテスト、ベンチマークテスト、並列テストについては references/advanced-testing.md を参照。
テスト作成時に以下を確認すること:
xxx_test.go の命名規則に従っている_test サフィックスがついているassert/require を使用しているmock.Anything の使用は必要最小限EXPECT() を定義。例: パスワード検証はトランザクション外なので先に、条件チェック・書き込みはトランザクション内なので後に期待値を設定する)| ファイル | 内容 |
|---|---|
| mock-patterns.md | mockery + testify/mock、httptest パターン |
| testcontainers-patterns.md | PostgreSQL、MySQL、Redis コンテナパターン |
| edge-cases.md | エッジケースの包括的リスト |
| advanced-testing.md | ファズテスト、ベンチマーク、並列テスト |
| concurrency-testing.md | 並行処理のテストパターン(ライフサイクル、Repository抽象化、レース検出) |
タスクが以下のいずれかに該当する場合、対応するリファレンスを Read ツールで読み込んでから テストを設計すること:
references/concurrency-testing.md を読むreferences/mock-patterns.md を読むreferences/testcontainers-patterns.md を読むリファレンスに記載されたテストパターンが該当するか判断し、該当するパターンをテスト設計に適用すること。「参照」ではなく「読み込んで適用」が必須。
ECC base commit
4e66b2882da9afb9747468b08a253ca2f09c85f3のskills/golang-testing/SKILL.mdを検証したが、本 skill の構造(references/に詳細を委譲する索引型 + プロジェクト固有規約 chi/GORM/testify 優先)と異なるため統合せず、全 H2 を conflicts として記録。ECC
golang-testingは idiomatic Go testing の汎用解説(720 行):
- 重複領域 (既存と重複、既存優先): Table-Driven Tests / Mocking with Interfaces / TDD Workflow for Go
- 既存: §テーブル駆動テストパターン, §モック作成パターン, references/mock-patterns.md,
tddskill- 既存になし (将来取り込み余地あり): Subtests and Sub-benchmarks / Test Helpers / Golden Files / Benchmarks / Fuzzing / HTTP Handler Testing / Test Coverage / Testing Commands / Integration with CI/CD
- 必要に応じて ECC 原文を
references/ecc-golang-testing.mdとして配置するか、特定章を抜粋して既存 reference に追記する形で将来取り込む(本 spec のスコープ外)- TDD は別 skill (
tddskill) に責務を委譲しているため、TDD 関連は本 skill に統合しない方針