Skip to content
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

Closed
talkol opened this issue Aug 10, 2016 · 11 comments
Closed

Support expectations on app logs #23

talkol opened this issue Aug 10, 2016 · 11 comments

Comments

@talkol
Copy link

talkol commented Aug 10, 2016

Allow to write tests over the app log

For example, expect that we have no errors or warnings in log

@talkol talkol added this to the Version 2 milestone Oct 6, 2016
@DanielZlotin
Copy link
Contributor

I would also like the ability to expect that a warning is shown

@LeoNatan
Copy link
Contributor

LeoNatan commented Mar 7, 2017

@DanielZlotin You mean RN warning? Open an issue with RN to have them add a testID to their warning and error views.

@rotemmiz
Copy link
Member

rotemmiz commented Mar 7, 2017

@LeoNatan no, actually expectations on device log emitted text.

@DanielZlotin
Copy link
Contributor

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).

@DanielMSchmidt
Copy link
Contributor

Could we borrow parts of the functionality from the local cli of react-native. More precisely this part. By using child_process.spawnSync (detached) return value and adding a stdout and stderr event listener we could actually achieve this cheaply. We could get native as well as JS logs at the same time and for android we could borrow that in a similar way.

Thinking about it, extracting this in a separate module might embrace further contributions and the usage in other projects.

@LeoNatan LeoNatan added the logs label Jun 6, 2017
@LeoNatan
Copy link
Contributor

LeoNatan commented Jun 6, 2017

I am not convinced that asserting on logs is a valid approach for testing.

@LeoNatan LeoNatan removed this from the Version 2 milestone Jun 6, 2017
@DanielZlotin
Copy link
Contributor

DanielZlotin commented Jun 8, 2017 via email

@rotemmiz
Copy link
Member

rotemmiz commented Jun 8, 2017

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.

@jgreen210
Copy link

Would need to take care that something are looking for in the logs isn't hidden in a buffer somewhere.

@LeoNatan
Copy link
Contributor

Thinking about this, on iOS this can, theoretically be achieved on the JS side alone, by running queries against the system log.

@LeoNatan
Copy link
Contributor

Closing old issues. This is out of scope.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants