Right now it's very similar to the JS test on Chrome. Like it, this one
just runs the "red.go" gio app, takes a screenshot, and expects to see
red.
It also supports the -headless flag; when true, Xvfb is used and it's
entirely headless and hidden. Otherwise, Xephyr is used and once can see
the test in action. If the tool isn't installed, the test is skipped.
We need to add xgb as a dependency, so that we can connect to the X
server and interact with it, like taking screenshots.
Finally, this is an initial version, and a number of TODOs are left for
a later time. They'll get fixed in follow-up patches.
While at it, start making all tests parallel, since the end-to-end tests
take about a second each and neither are very cpu-intensive.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
For example, if the browser doesn't have webgl at all, the gio app will
fail to load. This will result in the screenshot being incorrect,
without an apparent reason:
--- FAIL: TestJSOnChrome (0.89s)
js_test.go:122: got 0xffffffffffffffff at (5,5), want 0xffff00000000ffff
js_test.go:122: got 0xffffffffffffffff at (595,595), want 0xffff00000000ffff
The underlying webgl error was accessible if one added a sleep and ran
'go test -headless=false', allowing to open the console and see the
error messages.
Instead, capture them via chromedp and print them to the test's logger:
--- FAIL: TestJSOnChrome (0.89s)
js_test.go:79: console log: "2019/10/29 12:41:07 app: webgl is not supported"
js_test.go:79: console warning: "exit code:", 1
js_test.go:122: got 0xffffffffffffffff at (5,5), want 0xffff00000000ffff
js_test.go:122: got 0xffffffffffffffff at (595,595), want 0xffff00000000ffff
JS Exceptions are a completely different mechanism, so they're not
covered by this patch. We can add them at a later time if needed.
While at it, update to the latest tagged version of chromedp.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
This commit adds the first fully end-to-end test. It builds a very
simple Gio app, loads it on Chrome, and checks that it works.
To control Chrome, we use chromedp, a library in pure Go that takes care
of starting the browser and talking to it via the devtools protocol.
We add the test directly in the cmd module, since it mainly interacts
with the gogio tool, and also because the code might turn into some sort
of 'gogio test' command in the future. This does add chromedp and ui as
test dependencies to go.mod, but GOPROXY should allow a 'go get' of
gogio to not download their entire source code archives.
We don't replace ui with ../../ui in the go.mod, to ensure that testing
the cmd module works from anywhere without unintended differences.
The test app being used is inside a testdata directory, to ensure it's
not go-gettable, and that it doesn't otherwise affect the cmd module.
Finally, the test itself is pretty simple. The app just paints a red
background, and the test verifies that, once loaded, the background of
the browser viewport is indeed red.
The test does currently require Chrome or Chromium to be installed,
which is fine for now. It may also require a GPU, though I don't have a
headless machine to check for sure. The test uses Chrome in headless
mode though, so it doesn't open up any visible browser window.
All in all, the test succeeds in just over a second on my laptop with
Chromium 77.0.3865.75.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
If there is an appicon.png file in the main package the gio tool
will use it for Android and iOS apps in buildmode exe.
Signed-off-by: Elias Naur <mail@eliasnaur.com>
Elias Naur