Skip to content
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

Reduce overall testing time of juno through changes in REST tests #256

Closed
D-DePablos opened this issue Jul 1, 2022 · 7 comments · Fixed by #267
Closed

Reduce overall testing time of juno through changes in REST tests #256

D-DePablos opened this issue Jul 1, 2022 · 7 comments · Fixed by #267
Labels
Good first issue Good for newcomers

Comments

@D-DePablos
Copy link
Contributor

Tests currently take a long time because the rest api tests which are meant to fail (within /pkg/rest/tests/rest_test.go) take a long time to timeout.

This means that, while the rest of the test suite finishes in less than 10 seconds, all the Test(...)Fail take ~ 10s each, 13 times, incrementing this substantially and wasting time.

It would be good to have 1 timeout test with the normal rate, and the other failing tests to have a much smaller timeout or use a different method to check for failure than to wait out the full 10s.

@D-DePablos D-DePablos added the Good first issue Good for newcomers label Jul 1, 2022
@joshklop
Copy link
Contributor

joshklop commented Jul 2, 2022

Maybe we add a Config struct to the rest package where the user can adjust parameters like timeouts, protocol (http/https), etc? Then in the test we simply configure the package to immediately timeout.

I haven't explored this much, but wanted to post it here just in case the idea is useful.

@D-DePablos D-DePablos assigned D-DePablos and unassigned D-DePablos Jul 4, 2022
@D-DePablos
Copy link
Contributor Author

I think this issue is a bit more involved than I expected as the timeout is set at the client level, and there is no easy place to change this. Would yoiu like to have a go with your approach @joshklop ?

@joshklop
Copy link
Contributor

joshklop commented Jul 4, 2022

I can give it a try, but I may not be able to get to it for a bit.

@D-DePablos
Copy link
Contributor Author

Scope might have changed: It would be good to use the httptest standard library exclusively, instead of relying on external dependencies

@v4lproik
Copy link
Contributor

v4lproik commented Jul 4, 2022

Hi guys! I was working on another PR and as I was running all the tests, I also saw that the tests within rest_test.go were very slow. I looked at it and the problem is that the http client timeout will never be taken into account as you have an hardcoded time.sleep in you code here: pkg/feeder/feeder.go:129.

You need to extract the default retry function (the loop) implemented there without breaking the current implementation used by other functions. What you could do is allowing to pass a retry function as parameter. Something like that:

func (c *Client) do(req *http.Request, v any) (*http.Response, error) {
	retry := func(req *http.Request, c *Client, err error) (*http.Response, error) {
		var res *http.Response
		for i := 0; err != nil && i < 2; i++ {
			time.Sleep(time.Second * 1)
			res, err = (*c.httpClient).Do(req)
		}
		return res, err
	}
	return c.doWithRetry(req, v, retry)
}

This would allow you to pass a retry function from the tests and modify the sleep time and so by extention the timeout time.

Happy to open a PR if you guys want.

@joshklop
Copy link
Contributor

joshklop commented Jul 4, 2022

That looks awesome @v4lproik! Thank you so much. A PR would be great. If you need anything please let me know.

@v4lproik v4lproik mentioned this issue Jul 4, 2022
11 tasks
@v4lproik
Copy link
Contributor

v4lproik commented Jul 4, 2022

I decided to extend the client so it takes a retry mechanism function as parameter in NewClientWithRetryFuncForDoReq constructor. If the default constructor is being used then I initiate the retry function with the same piece of code that was hardcoded in the Do function before. Hope that helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants