New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Increase debugability #418
Conversation
This shows that sometimes |
8c649a4
to
2104cd6
Compare
For some reason, my compiler is flagging this line: // Ambiguous method call. Both
// verifyThat(Node, Matcher<Node>) in FxAssert and
// verifyThat(NodeQuery, Matcher<Node>) in FxAssert match
FxAssert.verifyThat(nodeFinder.lookup("#firstId").query(), is(firstIdLabel)); |
a36e38d
to
276cb4b
Compare
Ready for review. |
Alright I will check it out asap. Thanks very much for all the work! |
Note to self, example of a failed test with this PR (note debugging info):
|
b88d311
to
0d9c45a
Compare
@brcolow Do you think we should reduce the MouseMoved events? They're the ones that take up the most space on the console. I don't want to address that in this PR, but for a future one perhaps? |
I think that a future PR should probably in some way address the notion of where/how the information is printed (currently console stdout) such as json, html, etc. Then the mouse events can for example be hidden by default but expandable if they want to be seen. Also may want to look into Travis CI folding. |
The folding idea would be helpful |
Really great first step in making TestFX failures provide more useful information. Thanks again. |
As discussed in the Gitter Chat, a few other ideas for improving this work in a future PR are:
try {
matcher.match(node);
} catch (AssertionError error) {
throw`new AssertionError(mapper.apply(error.getMessage));
} |
Somewhat resolves #417.
The commit history needs to be cleaned up a bit, but this might help us track down the issues behind those flaky tests.
Regardless, I can't set the default error handler to automatically show which keys and mouse buttons were pressed since there's no access to
FxRobot
somehow. The event list makes this somewhat irrelevant, but I think that might be easier to read than the huge number of events.Also, I think the
errorHandler
should map the error's message. Otherwise, a person might return the original error and I'm not sure if that rethrows or not.