-
Notifications
You must be signed in to change notification settings - Fork 6
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
Refactor for testability #57
Conversation
9b29ce5
to
e92072b
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. Just some nits
} | ||
|
||
func handleCIStatus(status github.CIStatus) cli.ExitCoder { | ||
func handleCIStatus(status github.CIStatus, recheckInterval time.Duration) cli.ExitCoder { |
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.
Feels weird to have this new param just for logging purposes. This function looks like it shouldn't know about the interval and the log should be at a higher level
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. We should pass the logger via the struct or as a parameter or something, and have the config we want to log set as a field on that at a higher level. We could probably set that in the root even, to be honest. I'll look at doing that in a follow-up, cheers.
cmd/wait-for-github/ci.go
Outdated
return nil | ||
} | ||
|
||
func checkCIStatus(c *cli.Context) error { | ||
ctx := context.Background() | ||
type checkSpecificCI struct { |
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.
checkSpecificCI
. Not sure about the name. What part is specific?
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's the checks
field. When we use this one we call GetCIStatusForChecks
, it takes a slice of check/status names to look for and makes sure they are all there.
However you made me realise that the structs could be a bit better if the checks
slice wasn't in the checkAllCI
one, so I reorganised them and re-pushed. Thanks for that 👍
e92072b
to
781f8e6
Compare
In order to make the code testable one thing we need to do is eliminate the global state. That's what we do here. The handlers are turned into functions and they can have their own local state which they pass around.
Add a `Check` interface. This lets us separate out the part which is repeatedly called into their own functions. Then they'll be able to be tested.
Boilerplate removal
In an upcoming commit we will be testing the `ci` and `pr` subcommands. Splitting the interfaces into smaller components will make this a bit easier, since those testsuites will only have to fake what they need.
Now we've done all that refactoring, we can start to add more testcases sensibly. Actually, this particular commit would have been more or less possible already. Test the low-level github internal module. We've aimed for as close to 100% coverage as we can get, so there are a lot of cases.
781f8e6
to
760880a
Compare
This is part of a PR stack:
I started to add a new feature in #60, and wanted to add tests for it. But it turned out to be quite difficult due to the global state we have in the project, and the way the commands are constructed.
So here's a pre-PR with quite a bit of reorganisation of the code. I'll follow up with tests for the CI and PR subcommands, and then the new feature™.
Have tried to split the work into logical commits with each commit having a decent message, but if this is still too big to review then I can push each of those as separate PRs, just let me know. 👍