-
Notifications
You must be signed in to change notification settings - Fork 5
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
Move DeleteMachine
call outside Eventually
block in integration tests
#232
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.
Function call's result can be directly checked for success.
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.
Eventually block for delete can be simplified.
MatchError(ContainSubstring("NotFound")), | ||
)) | ||
g.Expect(err).Should(Succeed()) | ||
}).Should(Succeed()) |
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.
It can be simplified:
}).Should(Succeed()) | |
Eventually(func() error { | |
_, err := machineClient.DeleteMachine(ctx, &iri.DeleteMachineRequest{MachineId: createResp.Machine.Metadata.Id}) | |
return err | |
}).Should(Succeed()) |
This eliminates the need for the additional Gomega argument as well. Please update other occurrences accordingly.
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 are benefits? it looks more as cosmetic change. both solution are valid for gomega and this solution is more similar another eventually blocks.
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.
The functionality remains the same, but this approach offers advantages in terms of:
Readability: It explicitly conveys that the DeleteMachine call is expected to eventually succeed, eliminating the need for an additional Expect statement.
Clarity: Using Eventually(func() error { ... }).Should(Succeed()) directly signifies the expectation that an operation will ultimately succeed, avoiding the need for explicit error handling within the function.
However, this approach is optional and may vary based on preference.
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 implement it.
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.
fixed
provider/server/exec_test.go
Outdated
@@ -38,12 +38,14 @@ var _ = Describe("Exec", func() { | |||
Expect(createResp).NotTo(BeNil()) | |||
|
|||
DeferCleanup(func(ctx SpecContext) { | |||
Eventually(func(g Gomega) bool { | |||
Eventually(func(g Gomega) { |
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 don't think it is a good idea to call DeleteMachine
in an Eventually
block. We should call the delete method once and then ensure that the domain has been removed.
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.
no, it is DeferCleanup. It has to guarantee ideally clean environment. It is important, if you want to run test in loop on one environment. What you suggest we implemented in _delete.go test file.
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.
@afritzler do you understand why i want to have Eventually block for delete call? Can i close your comment?
1e7e3db
to
fdad6b6
Compare
test will be rewritten |
Fixes #218