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

Add test for history_replicator, ApplyEvent function #6004

Merged
merged 5 commits into from May 13, 2024

Conversation

bowenxia
Copy link
Contributor

@bowenxia bowenxia commented May 9, 2024

What changed?
Add test for ApplyEvent function in history_replicator.go, and NewReplicationTask in replication_task.go.
Refactored code to have newReplicationTask function as a parameter of historyReplicatorImpl.

Why?
Code coverage week.
Use newReplicationTaskFn as a parameter is to increase the testability. Doing it this way, we can pass in mock newReplicationTaskFn functions so that we can test ApplyEvent function as a whole, and test the functions it used in different unit tests.

How did you test it?
unit test

Potential risks

Release notes

Documentation Changes

Copy link

codecov bot commented May 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.91%. Comparing base (8821ae9) to head (43c2e30).
Report is 5 commits behind head on master.

❗ Current head 43c2e30 differs from pull request most recent head 0c39bce. Consider uploading reports for the commit 0c39bce to get more accurate results

Additional details and impacted files
Files Coverage Δ
service/history/ndc/history_replicator.go 17.13% <100.00%> (+4.09%) ⬆️

... and 6 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8821ae9...0c39bce. Read the comment docs.

eventsAffordance func() []*types.HistoryEvent
expectedErrorMsg string
}{
"Case1: empty case": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remark, no action required: I generally suggest starting from the full case first since it's the most laborious, and then working through the exception cases, it is just easier to delete stuff than to add it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, are all of these jsut error cases? Is there a test somewhere where we verify a successful application?

Copy link
Contributor Author

@bowenxia bowenxia May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet. There are so many branches in one function, I was trying to build a full case first, but looks like it is more efficient to build the successful case step by step from different fail cases gradually.

@@ -357,3 +360,196 @@ func TestNewHistoryReplicator_newMutableState(t *testing.T) {
)
assert.NotNil(t, testReplicatorImpl.newMutableState(mockDomainCacheEntry, log.NewNoop()))
}

func TestApplyEvents_newReplicationTask_validateReplicateEventsRequest(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like all the errors are from validateReplicateEventsRequest.
Might consider creating some function parameters and overwriting them in unit tests to mock these functions.
And you can write tests for individual functions separately to test those functions referenced by ApplyEvents.
Here is an example you can follow: #5971

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing idea! I've made refactors according to your advice. Please take another look when you got some time. 🙏

@coveralls
Copy link

coveralls commented May 12, 2024

Pull Request Test Coverage Report for Build 018f7345-3b84-4b56-91fc-2d821c405a8f

Details

  • 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
  • 37 unchanged lines in 10 files lost coverage.
  • Overall coverage increased (+0.05%) to 69.192%

Files with Coverage Reduction New Missed Lines %
service/history/queue/timer_queue_processor_base.go 1 77.66%
common/util.go 2 91.78%
service/history/execution/mutable_state_util.go 2 78.52%
service/history/task/transfer_standby_task_executor.go 3 86.21%
service/history/task/task.go 3 84.81%
common/task/fifo_task_scheduler.go 3 84.54%
service/frontend/api/handler.go 4 62.26%
service/history/task/fetcher.go 4 86.08%
service/history/execution/cache.go 6 74.61%
service/history/engine/engineimpl/poll_mutable_state.go 9 74.16%
Totals Coverage Status
Change from base Build 018f654f-6516-4478-ba10-1aa04729e008: 0.05%
Covered Lines: 101661
Relevant Lines: 146926

💛 - Coveralls

Copy link
Contributor

@Shaddoll Shaddoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you planning to add tests for success case in another PR?

@bowenxia
Copy link
Contributor Author

@Shaddoll Yes. I'll add success case later in another PR since it will need more refactor in applyEvent function.

@bowenxia bowenxia enabled auto-merge (squash) May 13, 2024 18:45
@bowenxia bowenxia merged commit 2813442 into master May 13, 2024
18 of 19 checks passed
@bowenxia bowenxia deleted the xbowen_history_replicator_test01 branch May 13, 2024 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants