Add a test verifying initial startup sequence #97
Conversation
Codecov Report
@@ Coverage Diff @@
## main #97 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 4 4
Lines 97 97
=========================================
Hits 97 97 Continue to review full report at Codecov.
|
See #95 (comment) From that discussion I wasn't sure whether the proposed the initial startup sequence of the limiter - i.e. whether at startup we always block, or always allow. Since we didn't seem to have that codified (perhaps apart from the `example_test.go`) this PR adds a test to verify this. This is still slightly (2/1000) flaky, but I think that's good enough to add this in - should be valuable anyway.
|
Well this one clearly needs more work. Works fine 998/1000 on my machine, but github runner is consistently unhappy. |
Turns out I just wasn't running |
|
@storozhukBM Could you take a look? Irrespective of the implementation changes I think we have a gap WRT behavior on the initial few requests. This seems useful to formalize in tests. |
* Add a test verifying initial startup sequence See uber-go#95 (comment) From that discussion I wasn't sure whether the proposed the initial startup sequence of the limiter - i.e. whether at startup we always block, or always allow. Since we didn't seem to have that codified (perhaps apart from the `example_test.go`) this PR adds a test to verify this. This is still slightly (2/1000) flaky, but I think that's good enough to add this in - should be valuable anyway. * channels are great
See #95 (comment)
From that discussion I wasn't sure whether the proposed the initial
startup sequence of the limiter - i.e. whether at startup we always
block, or always allow.
Since we didn't seem to have that codified (perhaps apart from the
example_test.go) this PR adds a test to verify this.This is still slightly (2/1000) flaky, but I think that's good enough
to add this in - should be valuable anyway.