Page MenuHomePhabricator

[services] Rust Integration - Backup - Rust - Fix wrong order of logs in the tests
ClosedPublic

Authored by karol on Sep 6 2022, 7:22 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 10, 6:57 AM
Unknown Object (File)
Tue, Nov 5, 11:29 AM
Unknown Object (File)
Sun, Nov 3, 7:01 AM
Unknown Object (File)
Sun, Oct 27, 8:13 PM
Unknown Object (File)
Sun, Oct 27, 8:13 PM
Unknown Object (File)
Sun, Oct 27, 8:13 PM
Unknown Object (File)
Sun, Oct 27, 8:13 PM
Unknown Object (File)
Sun, Oct 27, 8:13 PM

Details

Summary

Depends on D5071

Since some logs are pulled later and some sooner, we have to identify them by IDs instead of the order in which they come from the server. For example, if you have the logs of size 3MB, 3MB, 5KB, or 3MB, first you'll probably receive this of 5KB and only then the rest.

Test Plan

integration tests should pass for backup.

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek requested changes to this revision.Sep 9 2022, 5:44 AM

integration tests should pass for backup.

Is it the case that integration tests are failing now? If this is the case, which diff broke them? We have to make sure that tests pass after every diff.

services/commtest/tests/backup/backup_utils.rs
85–95 ↗(On Diff #16375)

We also need to check if there are no items that are included in result_log_map but aren't present in expected_log_map.

This revision now requires changes to proceed.Sep 9 2022, 5:44 AM
In D5072#148855, @tomek wrote:

Is it the case that integration tests are failing now? If this is the case, which diff broke them? We have to make sure that tests pass after every diff.

I'm not sure I follow here, sorry. Integration tests pass. What is the problem?

services/commtest/tests/backup/backup_utils.rs
85–95 ↗(On Diff #16375)

Sure. But I think it would suffice to check if there are no duplicated log ids. In this case, we perform insert on both collections the same amount of times, so they both have the same size. If so, when we iterate over only one of them and for each item check if the corresponding item exists in the other collection, then we're sure that they have the same set of keys. Correct me if I'm wrong.

In D5072#149159, @karol wrote:
In D5072#148855, @tomek wrote:

Is it the case that integration tests are failing now? If this is the case, which diff broke them? We have to make sure that tests pass after every diff.

I'm not sure I follow here, sorry. Integration tests pass. What is the problem?

In that case the problem is that your test plan

integration tests should pass for backup.

Doesn't check anything if the tests were passing before and after. To make this test plan really beneficial, we need to introduce a test that wouldn't pass before this diff but passes after it. Otherwise, how would we know if this diff improves anything?

This revision is now accepted and ready to land.Sep 12 2022, 2:56 AM

Ok, I see your point. It feels like you think I just never described what was wrong with those tests. I kind of described what was the problem in the description. Before this revision, the integration tests tended to not work because of the reasons I described. This revision eliminated this problem.

In D5072#149179, @karol wrote:

Ok, I see your point. It feels like you think I just never described what was wrong with those tests. I kind of described what was the problem in the description. Before this revision, the integration tests tended to not work because of the reasons I described. This revision eliminated this problem.

That makes sense, thanks!