-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add unit tests using Ginkgo #4
Conversation
Signed-off-by: Chetan Banavikalmutt <[email protected]>
Signed-off-by: Chetan Banavikalmutt <[email protected]>
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.
Looks great! There are some tweaks we might need to make to the original code, but we can look at those as part of a separate PR.
For now, let's get this one merged.
Some minor tweaks requested that I happen to notice while looking at the code outside the PR changes:
- Change
os.Exit()
->Fail("")
in test code - Couldn't hurt to add the weight value that is being updated to the log statement
slog.Info("updating route", slog.String("name", route))
Nginx Ingress
reference in the old code
return err | ||
} | ||
|
||
func (r *RpcPlugin) getRoute(ctx context.Context, namespace string, routeName string) (*routev1.Route, error) { |
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.
👍, Route client API is so much nicer than dynamic API.
// Kill which should do nothing | ||
c.Kill() |
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 see this was in the original test code, any idea what this is for? "which should do nothing" 🤔
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.
Looks like it got added from the rollouts-repo. I think it was included to verify if the plugin is configured in test mode. Since we are using it in a unit test it shouldn't do anything. But in production, it is expected to kill the plugin subprocess.
@ishitasequeira Please feel free to correct me.
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.
@chetan-rns you described it correctly. The kill basically kills the plugin process and makes sure that no pings are sent to it when the plugin is not running.
- Update logs and comments - Remove os.Exit Signed-off-by: Chetan Banavikalmutt <[email protected]>
9bc401a
to
73cfc7f
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.
LGTM, thanks @chetan-rns!
Fixes: #3