Skip to content

Configuration-based PluginTestHarness instead of plugin object#1468

Closed
SimonSapin wants to merge 2 commits intomainfrom
simon/harness
Closed

Configuration-based PluginTestHarness instead of plugin object#1468
SimonSapin wants to merge 2 commits intomainfrom
simon/harness

Conversation

@SimonSapin
Copy link
Contributor

No description provided.

@github-actions

This comment has been minimized.

Copy link
Contributor

@garypen garypen left a comment

Choose a reason for hiding this comment

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

I've speed-read through the changes and I think the direction is good.

I have got one question: How will a user know the valid configuration to supply for a plugin?

Apart from that, I really like the clean-up effect on the examples.

@SimonSapin
Copy link
Contributor Author

How will a user know the valid configuration to supply for a plugin?

It is true that when a user writes a json!( … ) macro they get less compile-time checks or IDE-provided guidance about the expected "shape" of plugin configuration, compared to a Rust struct literal. However tests for a plugin are typically written not far from the source code of that plugin so users can look there, and the new situation is no worse that using that plugin when writing a YAML router configuration file.

@SimonSapin SimonSapin force-pushed the simon/harness branch 2 times, most recently from 6bce52e to da8ba6c Compare August 5, 2022 10:29
@SimonSapin SimonSapin marked this pull request as ready for review August 5, 2022 10:29
@SimonSapin SimonSapin enabled auto-merge (squash) August 5, 2022 11:30
Copy link
Contributor

@o0Ignition0o o0Ignition0o left a comment

Choose a reason for hiding this comment

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

I like where this is going!

There's a few things I m not sure I understand, but it looks great overall!

.build()
.await?;
let graphql = harness.call_canned().await?.next_response().await.unwrap();
assert_eq!(graphql.errors, []);
Copy link
Contributor

Choose a reason for hiding this comment

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

nit

Suggested change
assert_eq!(graphql.errors, []);
assert!(graphql.errors.is_empty());

This imo would look more symetrical with the kinds of assertions apollo-rs does

let config = CSRFConfig::default();
let non_preflighted_request = RouterRequest::fake_builder().build().unwrap();
let non_preflighted_request = RouterRequest::fake_builder()
.header("content-type", "text/plain")
Copy link
Contributor

Choose a reason for hiding this comment

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

does the header() method replace or append a header?

Raising this because the changelog mentions When no Content-Type header is specified, this builder will now default to application/json which makes the request be accepted by CSRF protection. so I'd suspect the header value to now be ["application/json", "text/plain"] which would be kinda surprising?

Comment on lines +177 to +180
let result = replace_layer(Box::new(telemetry));
if cfg!(not(test)) {
result.expect("set_global_subscriber() was not called at startup, fatal");
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be overlapping with @Geal s work?

Copy link
Contributor

@Geal Geal Aug 5, 2022

Choose a reason for hiding this comment

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

this should not be necessary once #1463 lands. And with the current version of the code it smells like a workaround for a deeper issue 🙃
so idk, either dig into it or wait for the fix 😁

/// Returns `None` if the name or `Plugin` type does not match those given to [`register_plugin!`],
/// or if that plugin was not enabled in configuration.
pub fn plugin<Plugin: 'static>(&self, name: &str) -> Option<&Plugin> {
self.plugins.get(name)?.downcast_ref::<Plugin>()
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh this is why we have the downcast magic?

I see!

@SimonSapin SimonSapin disabled auto-merge August 5, 2022 12:12
@SimonSapin
Copy link
Contributor Author

After trying to follow this up by porting more things to use PluginTestHarness I’m now reconsidering this approach.

A lot of use cases involve manipulating a plugin instance. Already this PR does trait object downcasting to work around that, but having stuff in Arcs makes mutability more difficult.

Then I’m considering generalizing the harness API: instead of a MockRouterService, take something like BoxService<RouterRequest, RouterResponse>. But now that API starts looking a lot like the Plugin trait. So maybe the test harness should take a configuration and an (optional) plugin instance.

@SimonSapin
Copy link
Contributor Author

I will soon submit a PR with a different approach that supersedes this PR.

@SimonSapin SimonSapin closed this Aug 9, 2022
@abernix abernix deleted the simon/harness branch March 29, 2023 12:28
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.

5 participants