Use test host configuration to set playwright options.

[CZEMacLeod]

From #1 there is a possibility to load configuration for PlaywrightWebApplicationFactory from the host under test.

This would allow many options to be set without overriding the respective property get function:

• BrowserType
• LaunchOptions
• ContextOptions
• PageOptions

It would need to be decided what the configuration section name should be (at least by default) for these. In the proof of concept, I used.

protected virtual IConfiguration TestConfiguration => Services.GetRequiredService<IConfiguration>().GetSection("Playwright");

To separate settings for the host, from the test factory, it might make sense to load additional setting from an appSettings.json file in the test project, and/or from user secret linked to the test project.

The former can be achieved by code like

  /// <summary>
  /// Add the file provided from the test project to the host app configuration
  /// </summary>
  /// <param name="builder">The IHostBuilder</param>
  /// <param name="fileName">The filename or null (defaults to appsettings.Test.json)</param>
  /// <returns>Returns the IHostBuilder to allow chaining</returns>
  public static IHostBuilder AddTestConfiguration(this IHostBuilder builder, string? fileName = null)
  {
    var testDirectory = System.IO.Directory.GetCurrentDirectory();
    builder.ConfigureAppConfiguration(host => host.AddJsonFile(System.IO.Path.Combine(testDirectory, fileName ?? "appsettings.Test.json"), true));
    return builder;
  }

which could be called from CreateHost and the latter by

    builder.ConfigureAppConfiguration(config => config.AddUserSecrets<PlaywrightFixture>());

again in CreateHost.

Technically, we could do something like

builder.ConfigureAppConfiguration(config => config.AddUserSecrets(this.GetType().Assembly));

Which would work if the factory was subclassed as a fixture in the test project.
There is also a GetTestAssemblies function in the base Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory which could perhaps be used.

So, the questions are:

• Should this feature be added at all?
• Should it be enabled by default?
• What section name should it use (by default)?
• Should appSettings.json (or similar) be added from the test project by default?
• Should UserSecrets be added from the test project by default?

If should be possible to add predicate properties to allow overriding the default behaviour fairly easily - like

C3D.Extensions.Playwright.AspNetCore/src/C3D/Extensions/Playwright/AspNetCore.Xunit/Fixtures/PlaywrightFixture.cs

Lines 13 to 21 in d967c9e

	public virtual bool AddMessageSinkProvider => true;
	public IMessageSink MessageSink => output;
	protected override ILoggingBuilder ConfigureLogging(ILoggingBuilder builder)
	{
	if (AddMessageSinkProvider) builder.AddXunit(output);
	return base.ConfigureLogging(builder);
	}

[eric-vanartsdalen]

My knowledge is limited in Playwright framework... but what I have gathered for Playwright configuration...
Object instantiations hierarchical order occurs like this:
** Playwright (expensive) => Browser Type (expensive) => Browser (expensive) => Browse Context (cheap/fast) => Page context (cheap/fast) **
So Browser Type typically can take BrowserTypeLaunchOptions to help configure with overall environmental types...
... set for Chromium, Firefox or WebKit ... but with a little extra "Channels" also provide a way to specify chrome or msedge for use with the system's runtime installations...
Other common items set at this level: Headless, SlowMo, Timeout, DevTools, Network, Profile configs, etc...
So once a Browser Type is determined and configured, a Browser can be created => and then Browser Context session(s) can be created/destroyed as needed => the Page object is then created out of the context session and allows the operations on/within the page elements.
Browser context sessions can be configured for Tracing, Cookie session specifics, Snapshots, etc
Question: Does Playwright itself have a way to instance option POCOs from configurations for the areas where different configuration options can be applied easily?
My thought is maybe, and not wanting to reinvent the wheel...
Ideally, it would be good to allow the extension to easily ingest configurations so downstream users have flexibility for use.

[CZEMacLeod]

@eric-vanartsdalen Playwright uses a number of POCO configuration objects to performs various operations, such as BrowserTypeLaunchOptions, BrowserNewContextOptions, BrowserNewPageOptions, and TracingStartOptions.
The extensions for tracing for example, just create a TracingStartOptions with the parameters from the extension, and pass that to the StartAsync method of page.Context.Tracing.
This is what is used in the calls to CreateCustomPlaywrightBrowserPageAsync where you can pass an Action<BrowserTypeLaunchOptions> to change the value of the field Headless.
Right now, there are defaults created for these, e.g. Headless = true, or BaseUrl = Uri, which allows the use of relative URLs.
Using the built in Microsoft.Extensions.Configuration's Bind function, we can load these default POCO objects from the configuration, including any test and user secrets to e.g. override the default for Headless when running in an IDE, but use the default when building on a server.
Regarding object instantiation:

• Part of the reason to use a fixture is so that expensive setup operations, such as spinning up the application website, or Playwright, only occur once per test class.
• Creating Playwright itself isn't particularly heavy, unless it has to install the browser for the first time.
• Launching a Browser instance is one of the more expensive operations. This is why we do it during the lifecycle for the fixture. If your entire test class wants to use a different browser, or custom settings, you can derive a new fixture class for that test class, and override the appropriate Options property. (Similarly, you can override the default Environment for the AspNetCore host).

I think we are generally in agreement here on the customization that can be done.
By simply Binding the host configuration (or other configuration loaded in an overridden TestConfiguration property), we don't need to re-invent any wheels for the configuration and simply use the existing POCO objects.

See

C3D.Extensions.Playwright.AspNetCore/src/C3D/Extensions/Playwright/AspNetCore/Factory/PlaywrightWebApplicationFactory.cs

Lines 65 to 102 in 194c3e1

	protected virtual string TestConfigurationSection => "Playwright";
	private IConfiguration? testConfiguration;
	protected virtual IConfiguration TestConfiguration => testConfiguration ??= UseHostConfiguration ?
	Services.GetRequiredService<IConfiguration>().GetSection(TestConfigurationSection) :
	new ConfigurationBuilder().Build();
	private BrowserTypeLaunchOptions? launchOptions;
	protected virtual BrowserTypeLaunchOptions LaunchOptions => launchOptions ??= BindConfiguration(new BrowserTypeLaunchOptions()
	{
	Headless = true
	});
	private BrowserNewContextOptions? contextOptions;
	protected virtual BrowserNewContextOptions ContextOptions => contextOptions ??= BindConfiguration(new BrowserNewContextOptions()
	{
	BaseURL = Uri
	});
	private BrowserNewPageOptions? pageOptions;
	protected virtual BrowserNewPageOptions PageOptions => pageOptions??= BindConfiguration(new BrowserNewPageOptions()
	{
	BaseURL = Uri
	});
	private TracingStartOptions? tracingOptions;
	public virtual TracingStartOptions TracingOptions => tracingOptions ??= BindConfiguration(new TracingStartOptions());
	private T BindConfiguration<T>(T baseOptions, [CallerMemberName] string sectionName = null!)
	{
	TestConfiguration.Bind(sectionName, baseOptions);
	return baseOptions;
	}
	/// <summary>
	/// The default browser type to launch and used to create pages
	/// </summary>
	public virtual PlaywrightBrowserType BrowserType => TestConfiguration.GetValue("BrowserType", PlaywrightBrowserType.Chromium);

I've added a couple of example fixtures to show injecting/overriding configuration in the test and/or fixture.