element.typeText() will fail test when hardware keyboard connected

[mrozbarry]

For usage help, ask a question on Stack Overflow with the detox tag. The issues section of the project is meant for opening bug reports and enhancement requests of Detox. We use it to automatically track the change log

IMPORTANT: Use search before opening an issue. Duplicate issues will simply be closed.

Description

On the iOS simulator (iPhone 6), if I have Connect Hardware Keyboard checked, my tests on .typeText('...') because the software keyboard fails to open.

Steps to Reproduce

1. Create a view with a TextInput (mine has a testID set, if that matters)
2. Create an end to end test that calls await element(by.id('your-test-id-from-above')).typeText('test')
3. Run detox, and see it fail the test.

Detox, Node, Device, Xcode and macOS Versions

• Detox: 7.3.7
• React Native: 0.55.3
• Node: 9.11.1
• Device: iOS Simulator (iPhone 6)
• Xcode: 9.4
• macOS: 10.13.4 (17E202)

Device and verbose Detox logs

npm run detox -- --loglevel verbose &> log.txt

log

[mrozbarry]

Maybe related to #39 ?

[rotemmiz]

This is the expected result. EarlGrey looks for software keyboard and taps on its keys to emulate text writing.
With Xcode 9, xcrun simctl opens simulators in headless mode by default, so attached keyboards is not really a problem if you only write tests. When developing, you will have to manage it manually.

If you don't care about emulating all tap events and want to avoid all keyboard related issues use .replaceText('test') instead (I don't recommend it)

[mrozbarry]

Is that behaviour documented somewhere in this project? It wasn't clear to me that headless was the default (always had my simulator running), or that running in the simulator had that restriction. Even if it's documented here, but just links to EarlGrey's docs, as long as there is an easy trail for a lowly react app developer to follow.

[smrpr]

@mrozbarry it is: https://github.com/wix/detox/blob/master/docs/APIRef.ActionsOnElement.md#typetexttext

[rotemmiz]

Closing the issue, reopen if docs still don't satisfy you, or even better, create a PR.