Fix a long-standing TODO: instead of each sub-test handling its own
output separately, just make each expose its output via an io.Reader.
Then, the shared driverBase code can tell if any of the lines contain
the magic "gio frame ready" string.
Reduces the amount of code a bit, but most importantly, it keeps the "is
a frame ready?" logic in a single place.
In the future, this also enables us to do more with all the e2e test app
output consistently. For example, we might want to add a -debug flag to
always log output lines as they happen.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
The js/wasm bug meant that printing to stdout in the e2e app would crash
the runtime, so we couldn't synchronize with the app like in the other
drivers.
Now that the bug is fixed, we can do the same as the other drivers just
fine.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
We can instead synchronize with the gio app via stdout. We need three
states, since we need to first invalidate a frame and then print when
the next frame is drawn.
This is not happening on the JS test yet, because stdout printing
crashes in that case. See the comment.
This change should make the X11 test a bit faster on fast machines,
while making it more stable in small or headless machines like CI.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
The test app now responds to mouse clicks; clicking on one of the four
sections of the app flips it to red color until clicked again.
Add a Click method to the TestDriver interface, and implement it in both
of the current drivers. Unfortunately, I failed at implementing it in
X11 with the xdg library, after a few wasted hours. Instead, start
relying on more external tools which are simple to use and not heavy to
install.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
This vastly simplifies our code, and saves us the ugly math.
While at it, establish that a TestDriver must have a white background,
which is already satisfied by both existing implementations.
Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
The e2e app now splits the window into four rectangles and paints them
differently.
The first advantage is that we now test that we see the entire Gio app.
Before, with a solid background color, we could be seeing a small part
of the window and we wouldn't tell the difference.
The second advantage is that we test more colors. In particular, the
fourth color includes a different alpha value, which renders the same on
JS and X11.
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>
Egon Elbre