-
Notifications
You must be signed in to change notification settings - Fork 111
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
RSDK-6925 better helpers for resource manager tests #3795
RSDK-6925 better helpers for resource manager tests #3795
Conversation
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.
This file is a duplicate of robot/impltest/local_robot.go
for tests that are in the robotimpl
package. The TODO explains why we need both. If anyone has an idea of how to avoid this without making major restructures I'm all ears.
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.
this seems like a nice compromise
If you can't create a testing utilities package (due to docs, dependencies, etc.), try to move testing utiities to a single go file, and add comment //go:build testing on the top of the file. Then you can run tests with go test -tags testing ./.... This codes won't be contained in go build binaries.
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.
this has it's own problems: my linter complains unless this build tag is present on each test that uses this helper function - I imagine this will happen for others. And sadly there is no builtin testing build tag that is exposed to users. Proposals to add this have been declined thus far:
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 this breaks linting in other ways... okay I'm not going to down this path. will just have two duplicate helper functions for now
437156f
to
6cf2adc
Compare
remoteBot, ok := r3.RemoteByName("foo") | ||
test.That(t, ok, test.ShouldBeFalse) | ||
test.That(t, remoteBot, test.ShouldBeNil) | ||
|
||
remoteConfig.Remotes[0].Auth.Entity = entityName | ||
remoteConfig.Remotes[1].Auth.Entity = entityName | ||
_, shutdown = initTestRobot(t, context.Background(), remoteConfig, logger) | ||
shutdown() |
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.
we have some tests like this where we initialize a local robot and immediately close it. the new version of this test line captures the spirit of the assertion more explicitly IMO, since it's not obvious what shutdown
does without visiting the helper.
//revive:disable-next-line:context-as-argument | ||
func initTestRobot(t *testing.T, ctx context.Context, cfg *config.Config, logger logging.Logger) (robot.LocalRobot, func()) { | ||
t.Helper() | ||
|
||
r, err := robotimpl.New(ctx, cfg, logger) | ||
test.That(t, r, test.ShouldNotBeNil) | ||
test.That(t, err, test.ShouldBeNil) | ||
return r, func() { | ||
test.That(t, r.Close(ctx), test.ShouldBeNil) | ||
} | ||
} |
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.
just a note that this helper served as the model the share helper I am adding in this PR - the only real difference is the use of t.Cleanup
instead of returning a cleanup function
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.
Nice; I generally like the idea of relying more on t.Cleanup
. Have a question about double closing.
Using the Cleanup
pattern means that the "cleanup" of the test could be in the actual test or could be in some registered Cleanup
function from a helper. I don't love that ambiguity, but as long as we're consistently moving toward Cleanup
, I think it's probably a cleaner pattern than what we have now. We have a number of test failures in the NetCode "todo" that seem to have to do with forgetting to Close
some resource at the end of a test.
robot/impltest/local_robot.go
Outdated
// test if it cannot. It automatically closes itself after the test and all subtests | ||
// complete. | ||
// | ||
//nolint:revive |
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.
What is revive
complaining about for these helpers?
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.
context not being first argument - I tried to change this in our lint configurations but ended up having a very bad time, so just gonna have this ugly disable lint line. I'll add a comment so folks know why it's here
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.
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'm going to try to have a better time - I opened a PR to configure this more broadly
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.
merged - we don't need this lint exception anymore
actualR := r.(*localRobot) | ||
actualR.manager.moduleManager = mod | ||
|
||
resource.RegisterAPI(compAPI, | ||
resource.APIRegistration[resource.Resource]{ReflectRPCServiceDesc: &desc.ServiceDescriptor{}}) | ||
t.Cleanup(func() { |
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 assume multiple Cleanup
functions use a stack in the same way as defer
?
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.
yes per docs
Cleanup functions will be called in last added, first called order.
719956d
to
352a485
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.
general idea looks great, one question
robot/impl/utils.go
Outdated
"go.viam.com/rdk/robot" | ||
) | ||
|
||
// TODO: this duplicates `robotimpltest.LocalRobot` for tests that are in the `robotimpl` |
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.
whats the TODO here?
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.
removing the duplicate helper, if possible - here's some context on how I tried (and failed) to do that: #3795 (comment)
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 will add a ticket we can link this TODO to
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.
LGTM! Good ideas 🧑🔧 .
All stolen from folks who know better than me 👼 |
Adds a test helper version of robotimpl.New, which creates a local robot and automatically closes itself, and also fails tests on any failure. This fairly small helper ends up eliminating a lot of boilerplate code.
In addition, this PR also converts
defer
calls in test helpers to use T.Cleanup instead.