-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Removes global test client and calls setup for each client test #766
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
Removes global test client and calls setup for each client test #766
Conversation
This is a great start @chriskingnet, thanks! But see #762 (comment). |
Have made a few changes, based on the discussion from #762, and now also removed the |
CONTRIBUTING.md
Outdated
@@ -25,7 +25,7 @@ again. | |||
issue that you are planning to work on that bug or feature so that it can | |||
be assigned to you. | |||
|
|||
1. Follow the normal process of [forking][] the project, and setup a new | |||
1. Follow the normal process of [forking][] the project, and setup() a new |
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 change looks unintentional.
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.
Thanks for spotting, I have fixed this now.
On the the one hand, I think it'd be nice if this PR actually made use of the fact that tests are independent and made them run in parallel. That is the reason to be making these changes; if we don't make tests parallel, these changes have no positive effect. Also, making the tests run in parallel may uncover unexpected issues, ones that might result in us deciding to abort this change. It'd better to find that out sooner rather than later. On the other hand, we should merge this PR sooner, because it'll keep getting merge conflicts when other PRs get merged. What do you think we should aim for, @gmlewis and @chriskingnet? |
Ok, I see the original motivation for doing this in #732 (comment)... So even if making tests in parallel won't work, it's still worth to make the tests not share globals. In that case, I'm okay with this PR not making tests run in parallel, that can be a separate PR. |
Thanks for the comments, @shurcooL. I agree with the two step approach here - first remove the dependencies on the global variables, and then do the work to parallelise the tests. I am not sure what is going on here, though, I have tried to merge and resolve the conflicts, but it is still reporting them. I must be doing something wrong. |
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 is looking good, @chriskingnet! Thank you for doing this.
Just a few things requested in order to better document the new-and-improved setup
function and its return values, please.
@@ -42,9 +31,9 @@ const ( | |||
// setup sets up a test HTTP server along with a github.Client that is | |||
// configured to talk to that test server. Tests should register handlers on | |||
// mux which provide mock responses for the API method being tested. |
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 would like to capture the removed comments from lines 26, 29, 32, and 73 into the description of setup
so that it is clear what the purpose of the return values are.
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.
Thanks for spotting, @gmlewis. Have re-inserted in the new places they are built :)
CONTRIBUTING.md
Outdated
@@ -25,7 +25,7 @@ again. | |||
issue that you are planning to work on that bug or feature so that it can | |||
be assigned to you. | |||
|
|||
1. Follow the normal process of [forking][] the project, and setup a new | |||
1. Follow the normal process of [forking][] the project, and a new |
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.
Maybe revert all changes to CONTRIBUTING.md ?
Sorry for the delay on this. I have now merged master, fixed the newly added tests and reverted all comments that were caught in the find-replace. |
github/github_test.go
Outdated
func setup() { | ||
// test server | ||
mux = http.NewServeMux() | ||
func setup() (string, *http.ServeMux, *Client, 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.
Thanks, @chriskingnet! I was actually thinking about putting the comments into the setup
func comments immediately following line 44, but that's OK. As an alternative, I propose the following...
@shurcooL - for documentation purposes, what do you think about using named return values here?
I personally think it would make the code (and godocs) easier to understand:
func setup() (url string, mux *http.ServeMux, client *Client, teardown 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.
Agreed, named returned values would help readability. Seeing string
and func()
doesn't say much.
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.
Thanks for the input on this, @shurcooL. Have now included this :)
Have named return values. Good idea, thanks @gmlewis! |
github/repos_contents_test.go
Outdated
@@ -91,14 +91,14 @@ func TestRepositoriesService_GetReadme(t *testing.T) { | |||
} | |||
|
|||
func TestRepositoriesService_DownloadContents_Success(t *testing.T) { | |||
setup() | |||
serverBaseURL, mux, client, teardown := setup() |
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.
Minor, but I'd rename serverBaseURL
to just serverURL
for consistency with the return variable name in setup
. At least I don't see a good reason to give it a different, more verbose name.
github/github_test.go
Outdated
|
||
// github client configured to use test server | ||
// client is the GitHub client being tested and is | ||
// configured to use test server |
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.
Minor, missing period at end of sentence.
|
||
// server is a test HTTP server used to provide mock API responses. | ||
server *httptest.Server | ||
) |
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 have one major change request (and 2 minor nits, see above), but everything else looks great.
You've addressed Glenn's earlier concerns, so I think I can merge this after you apply these changes.
Thanks again for taking this on @chriskingnet!
github/github_test.go
Outdated
@@ -42,8 +31,8 @@ const ( | |||
// setup sets up a test HTTP server along with a github.Client that is | |||
// configured to talk to that test server. Tests should register handlers on | |||
// mux which provide mock responses for the API method being tested. | |||
func setup() { | |||
// test server | |||
func setup() (serverURL string, mux *http.ServeMux, client *Client, teardown 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've looked over the PR, and noticed that the vast majority of instances ignore serverURL
. In fact, it's only used in 1 place.
client
and teardown
are the most often used parameters, used in all instances.
mux
is used second most, missing in about 20-30% of them.
Since setup
is going to be called in so many places and in all future tests, let's optimize their order based on frequency of use. I think the following order would be better (most often used parameters first, except teardown
is always last):
func setup() (client *Client, mux *http.ServeMux, serverURL string, teardown func())
I just think that's going to look nicer than the _, mux, client, teardown := setup()
lines that we get now.
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.
Thanks for the feedback, @shurcooL. This is a very valid point, and something that is going to be used so often deserves this kind of depth of designing for sure.
I will make this change and also merge in any new tests again. Unfortunately I am unable to work on this until next week - but I will endeavour to get it done then.
Hi @shurcooL, I have merged master and I think I have changed everything. Sorry it took a few days for me to get around from it. I'm pleased with how this looks now - this parameter ordering is much better. Let me know if there is anything else you spot :) |
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. This looks really nice. Thank you for doing this @chriskingnet and @gmlewis for the idea!
This refactor removes the global test variables used by all tests, replacing them with local variables that are independent in each test. This is better style, easier to read and be confident about correctness, and allows tests to be parallelized in the future. Resolves google#762.
This is my attempt at removing the global client, as outlined in #762.
As I am a new contributor to this lib, I thought this might be a good issue to have a go at as suggested - as you get to see quite a lot of the test code. Also put my find and replace skills to the test! :D
This seemed to work, all the test keep running and it was achieved I think pretty much exactly as outlined in the issue.