-
Notifications
You must be signed in to change notification settings - Fork 805
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
Added new tests to config_Store_client_test.go #5983
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted filessee 44 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
* Added unit tests for history handler
…flow#5980) * TestRespondActivityTaskFailed_Success implementation * Alternate test for TerstRespondActivityTaskFailed * code lint
…-workflow#5981) This ensures they get included in the code coverage metrics.
…flow#5986) This test had three issues: 1. it's *very* time-sensitive, spending >=200ms across all StartWorkflowExecution calls will allow one (or more) of the "should be limited" calls to succeed. This is now more permissive. 2. it seems to misunderstand / be misleading about how ratelimits work. The reason the first 5 calls can be done "immediately" is due to the burst value, not the RPS itself. We just init the burst with that value. 3. if `assert.ErrorAs` failed, the next line would panic because the error value was nil. `require` would work too, but switching to `if assert.ErrorAs(...) {...}` lets the rest of the checks continue, and it's relatively simple. These are now fixed.
…rkflow#5967) Thankfully this all appears to be test-related and not any real risks, but I realized while writing some other code that `go test` doesn't check this. I'm really not sure what scenarios it might be wrong in, but it catches loads of incorrect concurrent code in my experience. So now it's required.
What changed?
Why?
coverage
How did you test it?
unit tests
Potential risks
Release notes
Documentation Changes