Expose TestServer as public property on RequestBuilder

[huysentruitw]

Expose TestServer as public property on RequestBuilder.

Addresses #5947

[Tratcher]

The code seems fine, but there's a problem with the intent. You did this so you could get access to the IWebHost and IServiceCollection. However, when we refactored TestServer for generic host it no longer holds a reference to either of those.

You might need to re-think the larger design here.

[carusology]

Thanks @huysentruitw for picking up this issue!

@Tratcher, I'm not sure I follow your comment.

When I look at the changeset you linked to, I see that there's still an public IWebHost Host property on L69 both after that changeset as well as in the latest pre-release of v3.0. When I look at the latest pre-release of the IWebHost definition, it still has a reference to the IServiceProvider.

With this changeset, this should complete the chain from RequestBuilder => TestServer => IWebHost => IServiceProvider. Is there something I'm missing? Are the constructors on TestServer that allow the injection of an IWebHostBuilder, and therefore a reference to its IWebHost, going to go away?

[Tratcher]

New 3.0 apps don't use IWebHost anymore, they've moved to IHost instead (which doesn't have a property on TestServer due to the redesign).

The new 3.0 templates:
https://github.com/aspnet/AspNetCore/blob/master/src/ProjectTemplates/Web.ProjectTemplates/content/WebApi-CSharp/Program.cs

[carusology]

Are the current v3.0 preview integration docs reflective of how we should be writing integration tests using the TestServer in ASP.NET Core v3? Assuming so, as long as we do not port our v2.X web application's TEntrypoint to use HostBuilder over WebHostBuilder, we will still have access to the TestServer via the public property on WebApplicationFactory, and the TestServer will still be hydrated with an IWebHostBuilder, and we'll continue to be able to the RequestBuilder that is being updated to expose the TestServer as part of this merge request, right? That certainly seems preferable to porting all of our existing integration tests to use HttpClient as well.

Assuming my above reading is correct, is there some benefit to using HttpClient over RequestBuilder to perform integration tests that we would be missing out on?

[Tratcher]

The WebApplicationFactory has been updated to work with either IHost or IWebHost. It's useful for testing larger components, especially full MVC apps.

TestServer is designed for unit testing individual middleware.

is there some benefit to using HttpClient over RequestBuilder

HttpClient has an ecosystem of libraries built around it for crafting requests and reading responses. That can be helpful for some scenarios. RequestBuilder is more helpful when you need to seed some of the server side structures directly.

When what you're really after here is the services, we should revisit making those available directly on TestServer and RequestBuilder. We don't need the IHost to do that, we could inject the IServiceCollection into the TestServer constructor.

[huysentruitw]

Anyone fancy to review my updates from 24 days ago? 😁

[Tratcher]

Sorry, hadn't noticed the updates. Looks better this time.

[Tratcher]

@huysentruitw were you going to be able to finish this up?

[huysentruitw]

@Tratcher I have a problem with this test when removing the parameter-less constructor for TestServer.

Now I need to pass a serviceProvider to new TestServer(serviceProvider), but it feels a bit weird to pass an empty service provider, while the .UseServer extension method adds the test server to an other service collection...

I think we need to remove this test as it probably demonstrates a usage we don't want to support. Or we could change the UseServer extension method so it takes a lambda instead, so we can do:

UseServer(serviceProvider => new TestServer(serviceProvider));

What do you think?

[Tratcher]

@huysentruitw Replace the UseServer call with AddSingleton<IServer>(services => new TestServer(serviceProvider));

[Tratcher]

Thanks

[carusology]

Thanks

No, thank YOU. This is a wonderful addition to TestServer that enables fluent API-styled extension methods.

I'm looking even more forward to ASP.NET Core v3!

h/t @Tratcher @huysentruitw