API 1.0 - PluginTestHarness is not good enough

[BrynCooke]

Recently we introduced a PluginTestHarness. It's very basic and needs to work. Things that need to be fixed:

1. Everything must be mocked. If you make a request then if it does not exactly match the expected then you get nothing back. This is super fragile, and doesn't allow the user to concentrate on the functionality they are adding.
2. Mocks need higher level configuration. Currently everything is very low level as we effectively expose mockall. We can use buildstructor to help here and allow people to for instance: assert_headers_contains or assert_response_containes_errors.

This will need several rounds of iteration.

[garypen]

We should start this soon and continue improving the test harness as we improve the APIs. We should consider using async_graphql to implement back end functionality. Should we include:

• [ ] Getting rid of federation-demo?
• [ ] How enable users verify without a lot of boilerplate (BuildStructor may be helpful)
• [ ] mockall must still be part of the solution

[SimonSapin]

https://github.com/apollographql/router/pull/1487 replaces PluginTestHarness with a new TestHarness API, but it’s still at roughly the same level of abstraction which is that of Rust plugins. There’s room for a lot more convenience APIs like assert_headers_contains.

[garypen]

This could be improved post 1.0, but it would be nice to have a good plugin testing story for 1.0. Leaving in for now and we'll see how the time goes. Consider this non-blocking for 1.0.

[o0Ignition0o]

I feel like we re good enough on that front, @garypen wdyt? can we close it?

[garypen]

@o0Ignition0o I don't think we should close it until we verify all the suggested improvements above are (or can be) addressed. I do think we can remove the 1.0 label, so I'll do that.

[o0Ignition0o]

sgtm, Seeing the board clear up is a good dopamine rush