SeleniumTest testAPI - run more tests client side, and test new API not Scratch Binding

[vorburger]

I've started extending our SeleniumTest with a new testAPI() to run more tests written in TS client side instead of in Java server side, and to focus on testing the new API, not the Scratch Binding.

Got reasonable far, but am now stuck with an issue I don't understand:

test.ts:53 Uncaught Error: INVALID_STATE_ERR
    at o.send (test.ts:53)
    at t._subscribe (test.ts:53)
    at t._trySubscribe (1.568a857938616d5c186c.hot-update.js:7)
    at t.subscribe (1.568a857938616d5c186c.hot-update.js:7)
    at t.test (test.ts:53)
    at HTMLButtonElement.onclick (?eventBusURL=http://localhost:6060/eventbus:20)

@edewit perhaps you could have a look at this, some time?

[vorburger]

Got reasonable far, but am now stuck with an issue I don't understand:

see vorburger@afe8327 - running that in the browser as described here reproduces above, and should hopefully make it easy to debug for you @edewit ? (Running SeleniumTest onsee vorburger@afe8327 makes it fail with something like #23, which is less clear.)

[vorburger]

@edewit pointed out that Uncaught Error: INVALID_STATE_ERR means we're using SockJS EventBus too early; and indeed a quick hack to use eb.onopen gets us past that (@edewit wants to nicely work that into the Minecraft wrapp class).

This uncovers another problem, for some reason this is not quite working yet:

awaitUntilJSReturnsValue("Client side test is not yet done", "tester.isDone()");

[vorburger]

this is not quite working yet

Selenium executeScript() doesn't know what do with the failures as Set object; RTFM, it's JavaDoc even says so. @edewit suggested to simply use a JS array instead, and that did the trick.

Enough for now. Future enhancement could be to use executeAsyncScript() instead of executeScript() with a throws for failures instead. In a sense I guess I'm writing a small Selenium / JS Test infrastructure framework here now...