-
Notifications
You must be signed in to change notification settings - Fork 3
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
chore: appium webdriver setup #926
Conversation
…ur app. Adjusting config for our needs.
…vironment variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a review per-se. More just questions and comments. I think it would be good for @gmaclennan to take a look at this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we create a readme in the config plugins folder to document what the increase in memory is for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I need Gregor's help with that. I know that the build fails and what the error message is, but I don't exactly know why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha I'm not sure either. Maybe just a doc to say "increase java memory to make builds work on CI"!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok done.
it('should launch the app, grant permissions, and navigate to the next screen', async () => { | ||
await browser.pause(15000); | ||
const description = await $( | ||
'android=new UiSelector().text("Map your world, together")', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we write reusable functions for these "strings"? Something like
function selectText(textToFind:string){
return `android=new UiSelector().text("${textToFind}")`
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do that in next PR when adding more tests. Thanks for suggestion but trying to keep things as simple as possible for this iteration.
wdio.conf.ts
Outdated
platformName: 'android', | ||
'appium:platformVersion': '12.0', | ||
'appium:deviceName': 'Samsung Galaxy S22 Ultra', | ||
'appium:automationName': 'UIAutomator2', | ||
'appium:app': process.env.BROWSERSTACK_APP_URL, | ||
'appium:autoGrantPermissions': true, | ||
'bstack:options': { | ||
projectName: 'CoMapeo', | ||
buildName: 'CoMapeo Android Build', | ||
sessionName: 'Launch App and Grant Permissions', | ||
appiumVersion: '2.12.1', | ||
debug: true, | ||
networkLogs: true, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are you getting this syntax from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A combination of from here:
https://appium.io/docs/en/2.0/guides/caps/ (specifies the appium prefix for all capabilities)
And here:
https://www.browserstack.com/docs/app-automate/capabilities
click legacy, node.js
Maybe you found syntax for Appium 1? This is for Appium 2+...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on this Cindy, I can see that a lot has gone into this, and it's amazing you were able to get all the moving pieces to line up and make this work. The overview about why choices were made is helpful too and the choices make sense to me based on what we know at this time. I think this is ok to merge and start using, and we can evolve and learn from it as we add more tests.
@ErikSin, before I merge this, are you good with running it
(for the workflow yml file?) |
I think it is good to merge. Perhaps in the future, if it takes a long time and is resource intensive, we could remove |
closes #908
Description of Choices Made
Driver:
Because we decided to use Browserstack and Appium, that lead naturally to the use of UIAutomator. That is what Browserstack uses with Appium. BrowserStack abstracts the driver implementation, and they implement UiAutomator with Appium automatically. In addition, UIAutomator can theoretically be used with our web app. Espresso is available through Browserstack, but it is its own entity, not the standard Appium implementation. We may want to test system-level features like GPS and Wi-Fi, which Espresso doesn’t handle well. I decided to go with the most supported, most fleshed out driver available on Browserstack.
Client:
Basically the same thing. I chose to use Webdriver IO because it is well-documented and actively maintained.
Great for multi-platform testing (mobile, web, and Electron). It has built-in integrations for BrowserStack and easier configuration for parallel test runs. It also has a large plugin ecosystem.
Test Framework:
I chose Mocha, a widely-used, flexible, and lightweight JavaScript test framework. It allows you to use any assertion library (e.g., Chai, Assert). It supports hooks like before, after, beforeEach, afterEach. It has simple syntax: describe and it. caveat... I am not sold on Mocha. Jasmine might be better and I am open to reconsidering.
Test Reporter:
I chose spec reporter. It provides quick and easy viewing of test results during local development and debugging with simple, human-readable output. It's pretty basic, imo ideal for getting started and debugging minimal test suites.
Testing
I wrote a simple test to check the first two screens and that you can get from the first screen to the second. It was not easy to figure out how to select text to test. I got my testing language from Browserstack's guidelines. But the same guidelines are available via WebdriverIO. It would be much much easier to look for text if we used accessibilityLabels on the text... Something to consider for the future?
Configuration file
I am really including the almost minimum that one can include in the configuration file. A lot more can be done with that, like testing on multiple devices, increasing number of instances, etc. Here's how the file can be adjusted from the docs: https://webdriver.io/docs/configurationfile/
Workflow
I built this based on previous work by Erik and Gregor -- Erik for signing into Expo and building using EAS. Gregor for building an apk. That increase to JavaHeapSpace (because I ran into out of memory errors when building) and work with caching and freeing up disc space (this makes the building of the apk at least 50% faster) comes from him. I wanted the test to not only fail in Github if the E2E tests failed, but I wanted an easy way for the PR maker to see why, since we only get 2 logins to Browserstack with our free account. In order to get that to work, each time someone makes a push, there is a file included summarizing the test results (this is where spec reporter comes in handy.
How to test
Push a new commit or open a PR to feat/appium-webdriver-setup.
GitHub Actions will automatically:
Build the APK using EAS.
Upload the APK to BrowserStack.
Run WebdriverIO tests on BrowserStack.
You should see the results as an artifact on the Workflow. LMK if you want my login to see how things look on Browserstack. With it I think you go to this link
To test locally
Start an Android emulator or connect a real device.
Run Appium in a separate terminal:
npx appium
Execute WebdriverIO:
npx wdio run wdio.conf.ts
or
npm run wdio
You will have to install appium locally to do this.
Next Steps: