You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CLAUDE.md
+9-1Lines changed: 9 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -159,11 +159,16 @@ cmd/memberagent/ # Member agent main and setup
159
159
## Testing Patterns
160
160
161
161
### Unit Tests
162
-
-Use `testify` for assertions
162
+
-Avoid the use of ‘assert’ libraries.
163
163
- Controllers use `envtest` for integration testing with real etcd
164
164
- Mock external dependencies with `gomock`
165
165
- Unit test files: `<go_file>_test.go` in same directory
166
166
- Table-driven test style preferred
167
+
- Use cmp.Equal for equality comparison and cmp.Diff to obtain a human-readable diff between objects.
168
+
- Test outputs should output the actual value that the function returned before printing the value that was expected. A usual format for printing test outputs is “YourFunc(%v) = %v, want %v”.
169
+
- If your function returns a struct, don’t write test code that performs an individual comparison for each field of the struct. Instead, construct the struct that you’re expecting your function to return, and compare in one shot using diffs or deep comparisons. The same rule applies to arrays and maps.
170
+
- If your struct needs to be compared for approximate equality or some other kind of semantic equality, or it contains fields that cannot be compared for equality (e.g. if one of the fields is an io.Reader), tweaking a cmp.Diff or cmp.Equal comparison with cmpopts options such as cmpopts.IgnoreInterfaces may meet your needs (example); otherwise, this technique just won’t work, so do whatever works.
171
+
- If your function returns multiple return values, you don’t need to wrap those in a struct before comparing them. Just compare the return values individually and print them.
167
172
168
173
### Integration Tests
169
174
- Located in `test/integration/` and `test/scheduler/`
@@ -181,6 +186,9 @@ cmd/memberagent/ # Member agent main and setup
181
186
182
187
### Test Coding Style
183
188
- Use `want` or `wanted` instead of `expect` or `expected` when creating the desired state
189
+
- Comments that are complete sentences should be capitalized and punctuated like standard English sentences. (As an exception, it is okay to begin a sentence with an uncapitalized identifier name if it is otherwise clear. Such cases are probably best done only at the beginning of a paragraph.)
190
+
- Comments that are sentence fragments have no such requirements for punctuation or capitalization.
191
+
- Documentation comments should always be complete sentences, and as such should always be capitalized and punctuated. Simple end-of-line comments (especially for struct fields) can be simple phrases that assume the field name is the subject.
0 commit comments