Include UI tests for blocks with Appium#676
Conversation
testId doesn\'t translate to android, so need to use accessibilityLabel
|
Tried out the PR @JavonDavis and works! I see the test running on an Android device 🎉 I will do another pass to have a look at the code side of things and report here again. Thanks! |
|
Hey @JavonDavis, this PR is a good start! I had a super quick look at the code changes too and I think I'll need some extra information on the individual changes to gain insight. So, can you please expand the PR description to include some detailed explanation of the individual changes introduced in this PR? I'll wait for that before adding comments as part of a PR review. Thanks! Also, it'd be good if you can have a look at the code correctness tests that currently fail on Travis. It'd probably be useful if you run A more crucial aspect of the new tests though is to manage to have them running on CI. Can you collaborate with our friends in Platform 9¾ for a plan? It'd be nice if we could add support for CI in this PR but, no problem if we opt for working on that on a separate PR. |
@hypest Definitely! This was still in draft mode so that's the reason I haven't included those details as yet, I'll update and ping you again
For sure! This is currently in progress, the plan is to use Firebase test labs with CircleCi to get this working. |
…rg-mobile into try/e2e-tests-appium
* Using data file for device tests
|
@hypest @pinarol This is ready for another look now... Sorry for the delay on this it took me some time to work through some issues building the app on the CI... Also my bad for the number of commits and changes in this one PR 🙈The addition of the CI really consumed me... Can you guys please take another look when you get a chance? |
| This repository uses appium to run UI tests. The tests live in `__device-tests__` and are written using Appium to run tests against simulators and real devices. To run these you'll need to check off a few things: | ||
|
|
||
| * For now you'll need run `yarn start`, and then either `yarn ios` or `yarn android` at least once before trying to run the tests on the respective platform | ||
| * [Appium cli](https://github.com/appium/appium/blob/master/docs/en/about-appium/getting-started.md) installed and available globally, I'd also recommend using [appium doctor](https://github.com/appium/appium-doctor) to ensure all of appium's dependencies are good to go. You don't have to worry about starting the server yourself, the tests handle starting the server on port 4728, just be sure that the port is free or feel free to change the port number in the test file. |
There was a problem hiding this comment.
It doesn't look like installing appium globally is actually necessary. It seems to work fine if we add it to our dev dependencies and just boot it using yarn appium.
There was a problem hiding this comment.
Right! I'll make that change, thanks!
| "preios:xcode10": "cd node_modules/react-native && ./scripts/ios-install-third-party.sh && cd third-party/glog-0.3.5 && [ -f libglog.pc ] || ../../scripts/ios-configure-glog.sh", | ||
| "ios": "react-native run-ios", | ||
| "test": "cross-env NODE_ENV=test node node_modules/jest/bin/jest.js --verbose --config jest.config.js", | ||
| "device-tests":"cross-env NODE_ENV=test node node_modules/jest/bin/jest.js --detectOpenHandles --verbose --config jest_ui.config.js", |
There was a problem hiding this comment.
We can use jest here instead of node node_modules/jest/bin/jest.js, yarn can look into node_modules/.bin
| <!-- wp:image --> | ||
| <figure class="wp-block-image"><img alt=""/></figure> | ||
| <!-- /wp:image --> | ||
|
|
There was a problem hiding this comment.
Minor but I'm curious we're removing empty lines here?
There was a problem hiding this comment.
I saw this in the diff and I meant to change out this back to the original and forgot to get back to it actually. My IDE keeps removing the empty lines
.circleci/config.yml
Outdated
| - run: | ||
| name: Install command line tools | ||
| command: | | ||
| sudo npm install -g react-native-cli |
There was a problem hiding this comment.
Same here, we can just use yarn react-native instead when we're inside the repository directory and dev dependencies are installed
There was a problem hiding this comment.
I think I attempted this and it resulted in an EACESS error on the CI. Let me try and dig up an old build in circle and see.
.circleci/config.yml
Outdated
| name: Bundle Debug android | ||
| command: | | ||
| mkdir -p android/app/src/main/assets | ||
| react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle --assets-dest android/app/src/main/res |
There was a problem hiding this comment.
Probably worth creating an npm script for that, we could call it bundle:android:test for instance
There was a problem hiding this comment.
Hmm yeah it's probably worth making that update. I'll make the change
|
Tested it with both platforms emulators and it worked great! Awesome work on that 👍 I'll review the code more thoroughly but so far it looks good, it could probably use a bit of cleanup though. Like, I'm not sure if |
pinarol
left a comment
There was a problem hiding this comment.
I thinks this looks good overall, I just added some minor comments and questions. Thanks for all your effort @JavonDavis ! Looking fwd to see our UI tests in action 🎉
|
|
||
| return ( | ||
| <View style={ styles.container }> | ||
| <View style={ styles.container } accessible={ false } accessibilityLabel="View Add block" > |
There was a problem hiding this comment.
Is the word "View Add block" used from somewhere? I can't find it when I search it. We can just remove it if it is unused?
Same for the below:
accessibilityLabel="Scrollview Add block"
accessibilityLabel={ 'Toolbar Add block' }
There was a problem hiding this comment.
It'd be good to choose a formatting strategy for accessibilityLabels just for sake of consistency(for those we don't have an option of using a localized title). I see in some places that they are separated by dash: "xxx-xxx", but in other places like "Xxx Xxxx Xx..."(I don't have a special choice BTW).
There was a problem hiding this comment.
Agreed, planning to sync with @etoledom on this. For now the ones you mentioned they were actually included for me to have a better understanding of how the hierarchy looked when translated to the XML view in the emulator to help me with debugging and identifying the right element. In that case they're not necessary or being used right now but I'd like to instead choose an appropriate and consistent name and leave them in to possibly help in the future. This can be more directly related to #476
src/block-management/block-holder.js
Outdated
| <View style={ [ ! isSelected && styles.blockContainer, isSelected && styles.blockContainerFocused ] }>{ this.getBlockForType() }</View> | ||
| <View | ||
| accessibile={ true } | ||
| accessibilityLabel={ this.props.testID } style={ [ ! isSelected && styles.blockContainer, isSelected && styles.blockContainerFocused ] }>{ this.getBlockForType() }</View> |
There was a problem hiding this comment.
we can beautify indentation here a bit
There was a problem hiding this comment.
True, I can make this update!
| <View style={ styles.toolbar }> | ||
| <View style={ styles.toolbar } > | ||
| <ToolbarButton | ||
| accessibilityLabel="toolbar" |
There was a problem hiding this comment.
how about we make this same as label where available: __( 'Move up' ) ?
That way in the future when we implement real accessibility it'd require us less refactor
There was a problem hiding this comment.
Yeah, toolbar here makes no sense and I think was there as placeholder when I was testing something else, I can change this name
Thanks for giving it a run @Tug. I'll look out for your feedback on the code! As it relates to |
| <BuildActionEntry | ||
| buildForTesting = "YES" | ||
| buildForRunning = "YES" | ||
| buildForRunning = "NO" |
There was a problem hiding this comment.
No sure what those mean, are we disabling the some types of build?
There was a problem hiding this comment.
Umm, this should not be necessary... No we're not disabling anything additional for this, this can be removed
There was a problem hiding this comment.
Actually my bad, this is necessary when building the app for the simulator, without this it leads to an architecture conflict when building the app
Part of #745
This is an initial PR to kick off on device UI tests.
It introduces:
appium-out.logfileHow it looks now
Before all
initial-html.jsfile is replaced with `initial-device-tests.html.js, this file clears out all the blocks and give the tests a blank slate to start withAfter all
Interacting with blocks
The challenge here is that blocks are created dynamically, with no reliable way for uniquely identifying a newly created block on fly(At a UI level at least). The change made here to facilitate this was to fit newly created blocks with a testID. The testID prop translates to accessibilityIdentifier on iOS and the content description on Android and is the recommended identifiers for locating elements on screen for mobile UI tests.
The testID for a block is a combination of the blockName and the the client Id. Specifically,
const testID = this.props.getBlockName( clientId ) + '-' + clientId;So a testID will look something like,
core/paragraph-667c78f0-2dcc-4cba-ab3c-aef6e9e96c44When new block is created it's searched for by it's prefixing blockName, then based on the set of blocks that existed before(based on the clientIDs) the new block is identified. With that reference to the new block you can go on to write new interactions with that block.
This PR starts by writing a test interacting with the Paragraph block and also adds useful testIDs in other areas of the sample app.
As an addition, from the spec for the
ToolbarButtonhttps://github.com/WordPress/gutenberg/blob/master/packages/components/src/toolbar-button/index.js, there is nolabelprop, I changed this totitlewhich I think was the intention here.To test
Run
yarn startAndroid(First time or after a change in the app code)
Ensure there's a connected Android Emulator or device
yarn androidiOS(First time or after a change in the app code)
yarn iOSAndroid
TEST_RN_PLATFORM=android yarn test:uiiOS
TEST_RN_PLATFORM=ios yarn test:uiUpdate
The testID value for a specific block will now look like
block-${ value.index }-${ this.props.getBlockName( clientId ) }For best practice and for easier constructing of identifiers without the need for client id which is an internal value which the user wouldn't have any knowledge of.
yarn test:ui:iosandyarn test:ui:androidWith the addition of these commands, the code used change out the initial-html file is removed.