-
Notifications
You must be signed in to change notification settings - Fork 142
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
Can View Inspector provide more descriptive errors when throwing? #155
Comments
Hey @nickg-ifit I'm happy to make the message more descriptive for this case, though could you provide an example of the hierarchy and the desired message thrown? |
Hmm. A text representation of the view graph would probably be helpful, just for the sake of understanding actual vs expected. What's most important is that from reading the message, I can easily tie that back to the actual line of code for the thing I was searching for. One of the errors I've seen thrown is a bit more helpful:
From this message, I can tell that the view I was even calling So in the case of For the text representation of the view graph, it might be useful if that were an extra property of the thrown error but not necessarily part of the default description that would print (that could make the logs annoyingly noisy if you had several successive failures, I think). |
Hey, I just realized the file and line of where the exception happened is actually logged by the test suit itself. Isn't it what you were looking for?
It is certainly possible to capture the caller's side file and line with I don't know how your CI is configured, but maybe a better course of action would be to make sure it logs the exception location automatically, as the Xcode seems to be capable of doing it. |
Using
XCTAssertNoThrow(try sut.inspect().find(text: "Hello World!"))
is a nice convenient way to assert whether or not my view contains a particular child, however in this case that this fails, the thrown error offers a fairly generic message:caught error: "Search did not find a match"
Would it be possible to update the apis such that thrown errors provide some details that make it easier to track down what it was actually searching for? If I write a unit test where I look for multiple children of the same parent view, it one of them fails, it can be difficult to track down which one actually failed (especially when running on a build machine, rather than locally).
The text was updated successfully, but these errors were encountered: