refactor: move ablytest under internal/ to make it unimportable externally - #707
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (34)
WalkthroughThe ablytest helper package moves from github.com/ably/ably-go/ablytest (and one instance of ably/internal/ablytest) to github.com/ably/ably-go/internal/ablytest. All test files referencing it are updated accordingly, a package doc comment is added to internal/ablytest/ablytest.go, and sandbox.go's relative path for locating test-app-setup.json is corrected. Changesablytest Package Relocation
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
…nally The ablytest package is test scaffolding for ably-go's own suite — in particular its sandbox helpers (NewSandbox etc.) provision test apps against the Ably backend, which is meant for developing and contributing to the SDK, not as an API for consumers of the package. Moving it to internal/ablytest makes Go's toolchain reject any import from outside this module. This is not a security boundary (the code can obviously be copied for a start), but rather an unambiguous request. We don't want to actually put any security barries in place, because we want SDK development to be open to all, and there's no way to verify whether a given test app will be used for SDK development or not. But at least we can make it unambiguous and avoid any unintentional reliance Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
851e80c to
affba27
Compare
The ablytest package is test scaffolding for ably-go's own suite — in particular its sandbox helpers (NewSandbox etc.) provision test apps against the Ably backend, which is meant for developing and contributing to the SDK, not as an API for consumers of the package.
Moving it to internal/ablytest makes Go's toolchain reject any import from outside this module.
This is not a security boundary (the code can obviously be copied for a start), but rather an unambiguous request. We don't want to actually put any security barries in place, because we want SDK development to be open to all, and there's no way to verify whether a given test app will be used for SDK development or not. But at least we can make it unambiguous and avoid any unintentional reliance
Summary by CodeRabbit