Test BrowserWindow WebPreferences Settings

Hello,

looking for guidance on how to unit test the webPreferences settings (enableRemoteModule, contextIsolation, etc) that were used to create the main window, in either the main or renderer process.

In the emocha tests for the main process I get the error that webPreferences property is not defined on the main window of the Electron app.

In the renderer emocha tests, I get the same result when testing on the window object.

Any advice ?

Thanks !

[inukshuk]

I’m really not sure how e-mocha running as renderer works. I assume it runs my Electron app and the window object would then allow me to run tests on the main window… ?

What is this assumption based on? How exactly would electron-mocha know about the webPreferences you use in your app? How would this work in apps that create different windows using different webPreferences?

Electron-Mocha runs Mocha in either Electron’s main process or in a renderer process. It runs your unit tests, it does not know anything about your Electron app at all (if you’re interested in integration tests, consider using something like Spectron).

In electron-mocha, if you run your unit tests in the renderer process, it uses its own webPreferences by default. If your renderer code makes certain assumptions about the environment (e.g., context isolation, a context bridge that exposes ‘electron’ on the global window object and this sort of stuff) it’s your job to create a suitable environment for the tests. Typically this is done using additional --require options and before hooks in mocha. You can also pass a custom --window-config as I’ve pointed out before (but electron-mocha will always run its own preload script).

I want to test that remote and other objects are not available in my app’s renderer, as per my webPreferences settings, would I use the window object for that ?

It’s not clear which window object you’re referring to, but the answer is no.

As I’ve pointed out before, if you want to test your window creation code, by definition, this is a test that must take place in the main process. To test only your own code you can stub BrowserWindow during the test to see the webPreferences your code passes in. If you want to test that the module really is not available in a window created by your code (that is, you’re not only testing your usage of the Electron API, but the actual window), then you have to create the window during your test and then run additional code in that window to test your assumptions.

window.electron.remote does not exist by default, I’m assuming, your own preload code creates a context bridge to expose it, so in your own window, yes, you should test to make sure it’s not available. You definitely also want to test that require('electron').remote does not work either.

But, again, you need to run these tests in a window that your own app created, if you want to test your window creation code. If you run it in electron-mocha’s default window you’re only testing electron-mocha’s environment which is rather pointless.

[inukshuk]

You’re right, you can get that object via webContents in the main process (not in renderer though!).

However, I doubt that this is reliable if you really want to test the effects of the preferences. I haven’t confirmed this, but I would expect the options to reflect only the values that were used to create the web contents, not necessarily whether or not they are in effect. For example, on macOS there’s a vibrancy option: even if you set it to true, the effect will only be applied if the current system preferences allow it – I would guess that in such a case the web preference option would indicate the setting is on even when it is not actually in effect for the window. So if you want to test, e.g. that a given code creates a window with the remote module disabled, I’d test this by making sure renderer code really can’t access remote.