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

Adding testing infrastructure to support sharded tests #1392

Merged
merged 7 commits into from
Oct 31, 2024

Conversation

cberkhoff
Copy link
Collaborator

Now we can start a sharded infrastructure for tests. I'm using the following changes to test the upcoming Query Workflow. I'm front-loading the tests that I will later use to make sure everything keeps working on every PR.

Created the TestApp struct which is used to create HelperApp by HTTP tests. HTTP Transport tests uses this new struct to spin up the hosts.

One of the certificates I had uploaded before was wrong so I'm updating it now.

I plan to breakdown tests.rs in a later PR, once the changes I have in the backlog are merged.

assert_eq!(apps[i * 3 + j].mpc_server.config.port, Some(port));
assert_eq_configs(
&apps[i * 3].mpc_network_config,
&apps[i * 3 + j].mpc_network_config,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I remember you added a function to compute that index, would it work here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Since I'm enumerating over the ports it won't be straight forward. I don't want to iterate over the computed results since they could have a problem (perhaps a missing ring), I rather iterate over the "known" result.

A1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyzSofZIX
XgLUKGumrN3SEXOMOAKXcl1VshTBzvyVwxxnD01WVLgS80/TELEltT8SMj1Cgu7I
tkDx3EVPjq4pOKNHMEUwFAYDVR0RBA0wC4IJbG9jYWxob3N0MA4GA1UdDwEB/wQE
MIIBZTCCAQugAwIBAgIITIDzw5k9qXIwCgYIKoZIzj0EAwIwFDESMBAGA1UEAwwJ
Copy link
Collaborator

Choose a reason for hiding this comment

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

what drove this change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think I had just copied it wrong in the first place and only now that I'm actually exercising it, saw the error

@@ -45,6 +46,38 @@ pub const DEFAULT_TEST_PORTS: Ports = Ports {
shards: [6000, 6001, 6002],
};

/// A network with two shards per helper.
pub const TWO_SHARDS: [Ports; 2] = [
Copy link
Collaborator

Choose a reason for hiding this comment

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

are we using this to spin up an actual server in unit tests? if so, I don't think we should do it - we have to pick ports randomly

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We have both tests. I can remove the one using this set.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I looked at the change and I don't understand whether we ever create a server with hardcoded ports or no. My line of thinking is that we should never need that - hardcoded ports are only good for config validation, everything else should use ports assigned by Kernel

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I modified the code so that we only use specified ports for config unit tests. All the HTTP tests now use OS given ports.

@@ -87,17 +120,18 @@ impl AddressableTestServer {
/// Either a single Ring on MPC connection or all of the shards in a Helper.
pub struct TestNetwork<F: ConnectionFlavor> {
pub network: NetworkConfig<F>, // Contains Clients config
pub servers: Vec<AddressableTestServer>,
pub servers: Vec<Option<AddressableTestServer>>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

is it what you want, or Option<Vec<..>> represents the state where you don't have ports assigned better?

Copy link
Collaborator Author

@cberkhoff cberkhoff Oct 31, 2024

Choose a reason for hiding this comment

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

Not really, in here is more of a rust ownership constraint.
I need to be able to take the server/ports out of this struct.

Copy link
Collaborator

Choose a reason for hiding this comment

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

this to me indicates that there is something off here. Consider consuming self and using servers.into_iter() to get AddressableTestServer instead of &mut Option<AddressableTestServer> that you can later replace

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sounds good. This was a vestigial change before I used destructuring and zip in the to_app function. It was simple to remove. Good catch!

Copy link

codecov bot commented Oct 31, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (main@6d29275). Learn more about missing BASE report.
Report is 9 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1392   +/-   ##
=======================================
  Coverage        ?   93.65%           
=======================================
  Files           ?      223           
  Lines           ?    37750           
  Branches        ?        0           
=======================================
  Hits            ?    35356           
  Misses          ?     2394           
  Partials        ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@akoshelev akoshelev left a comment

Choose a reason for hiding this comment

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

Thanks for addressing comments @cberkhoff, I like the conciseness of this change now. Great job simplifying the code

@cberkhoff cberkhoff merged commit ed0e488 into private-attribution:main Oct 31, 2024
12 checks passed
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.

2 participants