Multiremote support for TestLibrary

[Siolto]

Create multiple facades, depending on the amount of configured capabilities

[vobu]

scope fn questions

[vobu]

hm, browserInstance is explicitly passed in here → why is it not supposed to be used? IMO the browserInstance helps retain scope within the fn by explicitly not referencing the global browser

[Siolto]

Then we would have to initialize the facade as often as we have defined browsers in the config. That would look like something like this:

fioriElementsFacadeOne = await one.fe.initialize{...}

fioriElementsFacadeTwo = await two.fe.initialize{...}

We can do that of course, I just don't now if this is the best way

[vobu]

similar here - why remove browserInstance as parameter and instead break scope of the otherwise "pure" function?

[Siolto]

we never passed the second parameter to the initialize function. We only passed the config and just took the default for browserInstance

We could stick to that pattern, but then we have to pass the relevant browserInstance for the multiRemote in the before hook:

before(async () => {
        FioriElementsFacade = await browser.fe.initialize({appconfig}, browserInstance)
})

I guess we just have to decide what is cleaner

[Siolto]

scope fn questions

valid questions. I guess we have to do a short sync to decide which way is cleaner.

[vobu]

after an ad-hoc maintainer meeting (😸), we agreed to

• move the entire test library setup into the config (wdio*.conf.*), thus
• taking out the need to .initialize({}) from the test-scope and move it into the bootstrap of wdi5
• safe-guard the existing browser.fe.initialize(config) when called at test-scope so we don't cause side effects when moved into bootstrap-scope