-
Notifications
You must be signed in to change notification settings - Fork 27
Add unit tests for CLI and Auth packages #55
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
Conversation
Signed-off-by: amanycodes <amanycodes@gmail.com>
Signed-off-by: amanycodes <amanycodes@gmail.com>
|
Also cc: @aleksmaus @scunningham |
Signed-off-by: amanycodes <amanycodes@gmail.com>
Signed-off-by: amanycodes <amanycodes@gmail.com>
|
|
||
| // Log in for community rule updates | ||
| if token, err = auth.Login(ctx, baseAddr, ruleToken); err != nil { | ||
| if token, err = loginUserFunc(ctx, baseAddr, ruleToken); err != nil { |
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.
Definitely a matter of preference, but let's leave these function calls referencing the package instead of using the helper functions. Prefer to see dependencies immediately as we read the code, so seeing auth.X() or rules.Y() is helpful.
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.
Definitely a matter of preference, but let's leave these function calls referencing the package instead of using the helper functions. Prefer to see dependencies immediately as we read the code, so seeing auth.X() or rules.Y() is helpful.
I agree with the explicitness being more readable! But actually when I started the tests for initAndExecute I couldn't do direct calls to auth.Login and rules.GetRules since that was then depending on reaching to networks and I was having trouble as they were requiring complex setup. I would love your feedback on how to do this without the variable definition. Thanks!
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.
Ah that makes sense. I missed you were mocking them in the tests. All good. Can you leave comments above each call just noting why we're doing this? and note the original call in the comment?
tonymeehan
left a 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.
Looks good. Please fix up the function name helpers in cli.go and then we'll merge!
|
Added unit and integration tests for auth to:
|
|
@tonymeehan The changes are getting large, should I raise another one for the upcoming tests? |
Good idea. Let's do that. This is looking good, though. Merging now. Nice work improving the coverage! |
Added unit and integration tests for cli focusing to:
parseSourceswith valid, invalid an empty data-source files.rules.GetRulesandauth.Loginusing monkey-patching inInitAndExecuteto confirm option parsing.Since there was no dependency injection I couldn't use interfaces for rules.GetRules and auth.Login, so I wrote some package-level function variables for both helping me directly mock them in the test file and isolate them from other (network, fs, etc) dependencies.
Also. while writing tests I saw that the current
datasrc.Validate()anddatasrc.Parsefile()are more permissive and do not currently return errors for cases like: missing source key (considers file just with version: 1.0) and invalid source type (doesn't check the type field)I'll add these checks to the datasrc package once these are confirmed.
Looking forward for feedback and review! Thanks!
Partially closes: #48
cc @tonymeehan