Page MenuHomePhabricator

[services] Tests - Separate backup id from log id for pull backup
ClosedPublic

Authored by karol on Jun 28 2022, 4:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 1, 8:59 PM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM
Unknown Object (File)
Sat, Oct 26, 5:05 AM

Details

Summary

Depends on D4246

After a separation of log/backup IDs in D4245, we need to distinguish them in the test code as well.

Test Plan
cd services
yarn run-integration-tests backup

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Jun 28 2022, 4:59 AM
Harbormaster failed remote builds in B10044: Diff 13884!

CI failed because we use bare commands instead of the commands from the package.json

varun requested changes to this revision.Jun 28 2022, 10:34 AM
varun added inline comments.
services/commtest/tests/backup/pull_backup.rs
52 ↗(On Diff #13884)

we should be able to combine this match statement with the next one and terminate early if the right ID isn't provided for the response_data type

53–57 ↗(On Diff #13884)

i prefer we just say BackupID(id) and LogID(id). these are temporary variables so it's ok to use id in both

68 ↗(On Diff #13884)

shouldn't the asserts and expects be in the actual test function?

80 ↗(On Diff #13884)

shouldn't the asserts and expects be in the actual test function?

also, we should use assert_eq here

This revision now requires changes to proceed.Jun 28 2022, 10:34 AM
services/commtest/tests/backup/pull_backup.rs
52 ↗(On Diff #13884)

I wanted to do it like this but couldn't hack it.

53–57 ↗(On Diff #13884)

right

68 ↗(On Diff #13884)

Why? It's much easier to do it this way. Otherwise, we would have to terminate early, set a proper error, and panic in the outer scope. If we panic anyway, then why not do this here?

tomek added inline comments.
services/commtest/tests/backup/pull_backup.rs
68 ↗(On Diff #13884)

Overall, test assertions should be in test code and not in the utils. This case is a little different because the point of the whole binary is to test the system, so it might be ok. If this code had any other use except being a part of a test, I would insist on avoiding the assertion and returning error instead.

Even now, I think it would be better to not panic here and instead return an error, but we can keep the current solution if the change is really that complicated. This function already returns a Result so it shouldn't be that hard.

If we panic anyway, then why not do this here?

By panicking here we force a caller to use this particular approach to error. There are some other options, e.g. ignoring error, inspecting it, asserting something about it, forwarding it - by panicking we limit the available possibilities for a caller. Please note that a test could return Result instead of asserting - using this function makes it a lot more restricted.

This revision is now accepted and ready to land.Jun 29 2022, 3:16 PM

It still feels like an anti-pattern to have all these asserts and panics in a subroutine, but as @palys-swm said, it's not a big deal since this whole package is just for testing

apply changes after addressing feedback in D4245

services/commtest/tests/backup/pull_backup.rs
68 ↗(On Diff #13884)

Fair enough, I'm going to change this

This revision was landed with ongoing or failed builds.Jul 8 2022, 2:30 AM
This revision was automatically updated to reflect the committed changes.