btf: allow unit tests to run without network access#343
Conversation
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/btf/btf.go (1)
199-217: Use loadSpecFunc for consistency.Line 203 directly calls
loadSpec(path)instead of using theloadSpecFuncvariable. This bypasses the mocking infrastructure introduced by this PR and prevents tests from fully stubbing BTF loading inloadSpecFromCandidateLocations.Apply this diff:
- spec, path, err := loadSpec(path) + spec, path, err := loadSpecFunc(path)
🧹 Nitpick comments (2)
internal/btf/btf_test.go (2)
18-39: Consider stubbing saveDataToFileFunc for full isolation.The test successfully eliminates network dependencies, but
saveDataToFileFuncremains unstubbed, meaning the test still performs file I/O. While this verifies file creation (line 82:assert.FileExists), stubbing it would provide complete isolation and faster tests.If full isolation is desired, add:
origHTTPGet := httpGetFunc origDecompress := decompressXzReaderFunc origLoadSpec := loadSpecFunc + origSaveData := saveDataToFileFunc httpGetFunc = func(ctx context.Context, url string) (*http.Response, error) { return &http.Response{ StatusCode: http.StatusOK, Body: io.NopCloser(strings.NewReader("stub")), }, nil } decompressXzReaderFunc = func(src io.Reader) ([]byte, error) { return []byte("stub"), nil } + saveDataToFileFunc = func(data []byte, path string) error { + // Stub: no-op or minimal file creation + return nil + } loadSpecFunc = func(p string) (*ebpfbtf.Spec, string, error) { return dummySpec, p, nil } t.Cleanup(func() { httpGetFunc = origHTTPGet decompressXzReaderFunc = origDecompress loadSpecFunc = origLoadSpec + saveDataToFileFunc = origSaveData })Note: If you stub
saveDataToFileFunc, you may need to adjust theassert.FileExistsexpectation or create the file in the stub.
89-105: Consider stubbing saveDataToFileFunc for full isolation.Similar to
Test_loadSpecFromBTFHub, this test eliminates network dependencies butsaveDataToFileFuncremains unstubbed. For complete isolation and faster tests, consider stubbing it.Apply the same pattern as suggested for
Test_loadSpecFromBTFHub:origHTTPGet := httpGetFunc origLoadSpec := loadSpecFunc + origSaveData := saveDataToFileFunc httpGetFunc = func(ctx context.Context, url string) (*http.Response, error) { return &http.Response{ StatusCode: http.StatusOK, Body: io.NopCloser(strings.NewReader("stub")), }, nil } + saveDataToFileFunc = func(data []byte, path string) error { + return nil + } loadSpecFunc = func(p string) (*ebpfbtf.Spec, string, error) { return dummySpec, p, nil } t.Cleanup(func() { httpGetFunc = origHTTPGet loadSpecFunc = origLoadSpec + saveDataToFileFunc = origSaveData })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
internal/btf/btf.go(6 hunks)internal/btf/btf_test.go(2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
internal/btf/btf.go (1)
internal/log/log.go (1)
Infof(56-58)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build
- GitHub Check: unit-test
- GitHub Check: release-test
🔇 Additional comments (2)
internal/btf/btf.go (2)
18-23: LGTM! Clean dependency injection pattern.The function pointer variables enable test mocking without network access, directly supporting the PR objective. The naming is clear and follows Go conventions.
43-43: LGTM! Consistent use of function pointers throughout.All call sites correctly use the function pointer variables (
loadSpecFunc,httpGetFunc,decompressXzReaderFunc,saveDataToFileFunc), enabling comprehensive mocking in tests.Also applies to: 116-116, 122-122, 128-128, 132-132, 136-136, 149-149, 155-155, 165-165, 169-169, 216-216
Summary by CodeRabbit
No user-facing changes.