fix infinite loop with empty strategy list #2
Conversation
|
related with #1 |
|
This changes the |
func TestInfiniteLoop(t *testing.T) {
ts := httptest.NewServer(http.HandlerFunc(func (rw http.ResponseWriter, req *http.Request) {
// expected bad response for this test case
rw.WriteHeader(http.StatusInternalServerError)
rw.Write([]byte("Internal Server Error"))
}))
// this is simplified internal action with some logic for our business app
action := func(attempt uint) error {
resp, err := http.Get(ts.URL)
if err != nil {
return err
}
if resp.StatusCode != 200 {
return errors.New("bad response")
}
return nil
}
// this is simplified configuration, our app is configured from YAML
cfg := struct {
Strategies []strategy.Strategy
}{}
// we integrate retry library, but our tests with expected bad response are broken...
Retry(action, cfg.Strategies...)
} |
|
we have added check for empty cfg.Strategies (now it's so). if this is the right way, it's ok - I will remove PR and close the issue |
|
Yea, see the issue is that your test is invalid, or rather is incorrectly testing an expected condition. If you expect the Thanks for understanding. Please don't hesitate to let me know if I may be misunderstanding something. 😃 |
How I can fix that:
if len(cfg.RetryStrategies) == 0 {
result.retryStrategies = []strategy.Strategy{
strategy.Limit(0),
}
} else {
result.retryStrategies = cfg.RetryStrategies
}
if len(strategies) > 0 {
retry.Retry(action, strategies...)
} else {
action()
}:( |
|
Just imagine that the strategy list is configurable from outside the project. From etcd, json, yaml, etc. It can be different for many cases in runtime (if graceful degradation enabled or balancer decrease upstreams count). |
It depends on what you're actually trying to test vs what you actually want your code to do. Do you want your application (not tests) code to infinitely retry? In some service cases that may make sense, but in others you may want to limit the retries to a certain amount. If you don't want your application code to infinitely retry, then simply limit it by passing a If you do want your application code to infinitely retry, then your tests that test an error condition should work around the application's need to actually behave in that manner of retying infinitely or a number of times. This can be achieved via a "default" of some sort with an override, much like the configuration that you previously mentioned. If your test doesn't doesn't work around the actions need to retry, then it's not actually testing the behavior correctly. Your tests shouldn't test the behaviors of this retry library, but they should test that the action is actually being performed by the retry loop. 😃 |
|
Sorry for any confusion. Thanks for taking the time to work this out with me. 😃 |
Ready to write test if @Rican7 not against the patch
TODO: