-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testutils: add storageutils
test utilities
#83389
Conversation
02f7c3c
to
5da9b72
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I did a fairly mechanical review, operating under the assumption that a lot of this was copypasta, and then some mechanical changes to the tests to make use of the new (for now, duplicate) utils / helpers.
Reviewed 19 of 19 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @aliher1911 and @erikgrinaker)
This will (hopefully) be addressed separately.
It sounds like we want the utils moved out of storage
and into storageutils
. Then storage
(both the test and lib targets) can have a dep on this new package, removing the need for duplication? Or is it more nuanced than that?
If that sounds right, I'll create an issue and we can get this cleaned up in the background.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, and this is all fairly straightforward code. TFTR!
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @aliher1911 and @nicktrav)
Previously, nicktrav (Nick Travers) wrote…
This will (hopefully) be addressed separately.
It sounds like we want the utils moved out of
storage
and intostorageutils
. Thenstorage
(both the test and lib targets) can have a dep on this new package, removing the need for duplication? Or is it more nuanced than that?If that sounds right, I'll create an issue and we can get this cleaned up in the background.
Not that simple, I'm afraid. storageutils
must depend on storage
, because it needs e.g. storage.MVCCKey
, but that means that the tests in storage
can't depend on storageutils
, because it depends on storage
, so it's a circular dependency.
For this to work, all storage tests must be in storage_test
, which depends on storageutils
, which depends on storage
.
I really wish it would be possible to just import _test.go
contents from a different package, so e.g. batcheval
could just import test utils from storage
, but no such luck -- this is the canonical way, apparently.
5da9b72
to
97fdacb
Compare
This patch adds a bunch of test utilities to `storageutils`, replacing the old `sstutil` package. This is done to ease testing of MVCC range keys in tests outside the `storage` package. Unfortunately, these are mostly duplicates of utilities in `storage`. Storage tests use the `storage` package rather than `storage_test`, and can't make use of `storageutils` yet because it causes an import cycle with `storage`. This will (hopefully) be addressed separately. Release note: None
97fdacb
to
da020b0
Compare
CI failures are unrelated. bors r=nicktrav |
Build failed (retrying...): |
Build failed (retrying...): |
Build succeeded: |
This patch adds a bunch of test utilities to
storageutils
, replacingthe old
sstutil
package. This is done to ease testing of MVCC rangekeys in tests outside the
storage
package.Unfortunately, these are mostly duplicates of utilities in
storage
.Storage tests use the
storage
package rather thanstorage_test
, andcan't make use of
storageutils
yet because it causes an import cyclewith
storage
. This will (hopefully) be addressed separately.Release note: None