一键导入
goravel-testing
Goravel test-writing and test-running conventions. Use this skill when adding, updating, reviewing, or running tests in Goravel repositories.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Goravel test-writing and test-running conventions. Use this skill when adding, updating, reviewing, or running tests in Goravel repositories.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Planning workflow for Goravel tasks. Use this skill whenever the user asks for a plan, investigation, or implementation outline and the response should show both the concrete code change and the real user-facing code that the change enables.
Create or update the pull request for the current branch and enforce a strict PR body format. Use this skill whenever the user asks to create a PR, update PR description, sync PR text with latest branch logic, or asks for Summary/Why style PR content.
Workflow for addressing pull request review comments. Covers when to change code, when to push back on incorrect feedback, and when to answer questions without modifying code. Use this skill whenever the user asks to resolve, address, or respond to PR review comments.
基于 SOC 职业分类
| name | goravel-testing |
| description | Goravel test-writing and test-running conventions. Use this skill when adding, updating, reviewing, or running tests in Goravel repositories. |
go test ./... unless ask to run all tests explicitly.go test <pkg> or -run <TestName> over go test ./... (slow).testify/assert with assert.*(t, *) or require.*(t, *) directly, not assert.New(t).testify/suite for related test groups, and use s.*(*, *) when asserting.EXPECT method for mocks; avoid mock.Anything.assert.AnError if needed, and assert.Equal for error assertions.mock.MatchedBy; use it only for dynamically-generated args..Once() or .Times(), only use .Maybe() when necessary; avoid no-op expectations.Test<FunctionName>_[Optional]; use table style or sub-tests for multiple cases.assert.* with if statements; use assert.* directly for clarity and better failure messages.t.Run() for sub-tests when testing multiple cases for the same function, and use table-driven tests for multiple cases with similar setup/assertions. Avoid writing separate test functions for each case when they share common logic.import (
[system packages]
[third-party packages]
[internal packages]
)
func TestFunction(t *testing.T) {
// The name should start with `mock` to indicate it's a mocked function.
var (
ctx context.Context
mockFunc *mocks.MockedInterface
)
beforeEach := func() {
mockFunc = mocks.NewMockedInterface(t)
}
tests := []struct {
name string
input any
setup func()
expect any
expectError error
}{
{
name: "should do something",
input: someInput,
setup: func() {
mockFunc.EXPECT().SomeMethod(someArgs).Return(someResult, nil).Once()
},
expect: someResult,
expectError: nil,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
beforeEach()
tt.setup()
result, err := FunctionUnderTest(tt.input)
assert.Equal(t, tt.expect, result)
assert.Equal(t, tt.expectError, err)
})
}
}