[Question/Usage] How to configure electron and browser support using projects

[JonMarbach]

Apologies if this really belongs in the discussion section, but I've looked at the electron example, and I've looked at the projects feature, but it's not clear how to put it all together to achieve what I want to do... Maybe I should describe (a slightly simplified version of) what I'm trying to do first.

I'm developing an electron app and that will be the primary way that we run tests once they are established. The app launches a webserver at a known port, and contains a login page and a main page. In development mode however, we launch the webserver manually and we use Chrome for development of the frontend. Since we use Angular, that version of the frontend is at a different URL (via ngserve.)

So, it looks like the projects feature (have an electron project and a dev project, with different baseUrls; the electron project can have a dependency on yet another project named "electron-launch" which will launch the webserver.) A few questions come up:

1. We don't want both projects to run by default - is there a way to mark a project as dont-run-by-default?
2. How do we "abstract away" whether the page object is an electron page or a browser page for the same suite of tests. I've read a lot of the docs but it's not "clicking" for me (but I feel like it's possible.)
3. Can someone "sketch this out" for me? I'm a little lost with the different abstraction layers (fixtures sound like part of the answer but like I said, it's not gelling for me how to put this all together.)

Or do I have it all wrong and projects are the wrong way to do this!?

Thanks in advance! Playwright is amazing!

[dgozman]

We don't want both projects to run by default - is there a way to mark a project as dont-run-by-default?

This is not supported today. I'd recommend two separate config files, or two separate npm scripts.

How do we "abstract away" whether the page object is an electron page or a browser page for the same suite of tests. I've read a lot of the docs but it's not "clicking" for me (but I feel like it's possible.)

The easiest would be to override page fixture. You want to leave it as is when running in Chromium, and change to electron page when running in Electron. Here is a similar setup in Playwright repository, but you will need a conditional branch.

Can someone "sketch this out" for me? I'm a little lost with the different abstraction layers (fixtures sound like part of the answer but like I said, it's not gelling for me how to put this all together.)

Perhaps someone from the community could help?

[JonMarbach]

@dgozman Thank you - that helps a lot! More questions though...

This is not supported today. I'd recommend two separate config files...

That could be fine; or if we are passing an argument anyway, we could use projects and always specify the project (if that's equally recommendable?) If we go with two configs, I assume that one config would pull in the overridden fixture code that you pointed to (via require), and the other would just not.

The easiest would be to [override page fixture] ... but you will need a conditional branch.

Conceptually I understand what you're suggesting, but I'm more of a basic javascript guy, so can you say just a little more? I think I'd have to have conditionals in page and context, like this:

page: async ({ newWindow, configOptions }, run) => {
if( configOptions.name === 'electron' ) /// Making a guess here
{
await run(await newWindow());
}
else
{
await super.page(run);
}
},

I think with this much (answers to the above) I can be off and running. Thanks in advance!

[dgozman]

If we go with two configs, I assume that one config would pull in the overridden fixture code

Yep, it should be easier with two configs. I'd just set process.env.RUN_IN_ELECTRON in one of the configs, and then conditionally override the fixture. Something like this:

// fixtures.ts
export * from '@playwright/test';

import { test as base } from '@playwright/test';

let extended = base;
if (process.env.RUN_IN_ELECTRON) {
  // Extend with electron harness: newWindow, page, etc.
  extended = base.extend({ ... });
}

export const test = extended;

Reading the fixtures guide should help a bit.

[JonMarbach]

Thanks @dgozman . It's starting to click for me. I have read the fixtures guide a few times and I just re-read it again. I have to say that I've always understood the first ~25%, after that it gets murky (the auto-injection via { nameOfAThing } and 'use' being a function and a property in seemingly the same context are stumbling blocks for me), but it's getting clearer. I think the fixtures-options section is what made me think that projects would be the right way to do what I'm trying to do, but your suggestion seems simple enough.

I'll leave this open for a minute to see if I hit any other hurdles. Thanks for the guidance.

[JonMarbach]

@dgozman I'm making some progress based on your suggestions, but I can't figure out how to set a baseUrl on the fixture. In the fixture code I tried this:
extended.use( { baseURL: 'http://localhost:18100' });

But in frames.js around line 515:
const constructedNavigationURL = (0, _utils.constructURLBasedOnBaseURL)(this._page._browserContext._options.baseURL, url);

this._page._browserContext._options.baseURL is undefined. And I notice here that the baseURL is stored on the browserContext options, so I stumbled around trying to add that to context, but my attempts are so embarassing I'm not going to post them here.

I see this person had a similar problem: https://stackoverflow.com/questions/73048118/using-a-fixture-to-override-the-baseurl-is-not-working-with-page-goto

[dgozman]

@JonMarbach baseURL should work when you use default page and not use your electron fixtures. If that's not the case, could you please file a new issue and provide a repro? We'll be happy to look into it. Also, this SO question is a different thing, there's some misunderstanding of how URL completion works.

With electron, baseURL is just not implemented today, for example there is no such option in electron.launch(). In addition, baseURL and some other options from the config are not wired up for electron, see #8208. Overall, electron support is experimental, and there are some rough edges at times. If you are willing to contribute to any of electron issues, we are open to PRs.

[JonMarbach]

@dgozman OK. Thank you. I understand it might be a little rough around the edges. We may end up launching the electron app but using the built-in chromium support for the time being (if necessary.)

Speaking of (potential) rough edges: I seem to be having some trouble with page.waitForURL and page.waitForNavigation. I don't know if it's related to the electron fixture or the fact that we are using Angular and I'm trying to watch for "hash navigation" (asynchronously, after a click and some backend processing, our page changes from http://my.url/site#/login to http://my.url/site#/ ). I've tried searching for issues related to SPAs/Angular/hash and I don't see anything conclusive one way or the other. I guess the question is: should I expect waitForURL and/or waitForNavigation to trigger on a hash change? Or should I suspect a problem with the electron fixture?

(Side note, I did find this Puppeteer issue about hash navigation and was surprised (not in a bad way) to see many familiar names there. puppeteer/puppeteer#257 )

RE baseUrl, new issue + repro: I'll try to find the time to do so. Thanks for the help/advice so far.

[dgozman]

@JonMarbach waitForURL should work for a hash change. Same goes for waitForNavigation, but it is hard to use correctly, so better stick with waitForURL.

RE baseUrl, new issue + repro: I'll try to find the time to do so.

Sounds great!

Thanks for the help/advice so far.

You are welcome! I think we have achieved reasonable success in this issue, so I will close it now. If you later stumble upon more specific problems, please file a new issue for each. Thank you and enjoy Playwright!