-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Support expectations on app logs #23
Comments
I would also like the ability to expect that a warning is shown |
@DanielZlotin You mean RN warning? Open an issue with RN to have them add a |
@LeoNatan no, actually expectations on device log emitted text. |
Preferably, we need to provide assertions on NSLogs while running the e2e suite, because getting the logs manually and running unit tests on them requires a complete new test runner instance which must run after detox. If possible also in Release build (for CI). |
Could we borrow parts of the functionality from the local cli of react-native. More precisely this part. By using Thinking about it, extracting this in a separate module might embrace further contributions and the usage in other projects. |
I am not convinced that asserting on logs is a valid approach for testing. |
I agree, but relying only on UI will make some things extremely hard to
test. I'm talking weird edge cases.
Having the ability to get the logs out into the test runner is enough (into
the js).
…On Jun 6, 2017 10:57 PM, "Leo Natan" ***@***.***> wrote:
I am not convinced that asserting on logs is a valid approach for testing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGWgj3U3UGBdp8HxoTgXkjfpgpQ17w8Vks5sBa83gaJpZM4JhUIG>
.
|
I strongly believe that this is a must, at least in black box testing frameworks. We probably can do something smarter and more robust in gray box, but I think it will be very hard to implement. Until we come up with a better idea, I think we should support it. |
Would need to take care that something are looking for in the logs isn't hidden in a buffer somewhere. |
Thinking about this, on iOS this can, theoretically be achieved on the JS side alone, by running queries against the system log. |
Closing old issues. This is out of scope. |
Allow to write tests over the app log
For example, expect that we have no errors or warnings in log
The text was updated successfully, but these errors were encountered: