[VBLOCKS-3535] feat: proof of concept appium testing

[mhuynh5757]

Submission Checklist

• Updated the CHANGELOG.md to reflect any feature, bug fixes, or known issues made in the source code
• Tested code changes and observed expected behavior in the example app
• Performed a visual inspection of the Files changed tab prior to submitting the pull request for review to ensure proper usage of the style guide

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

• I acknowledge that all my contributions will be made under the project's license.

Description

This PR adds a proof of concept test to the repo test app using appium.

Breakdown

• Add appium automated testing to the test app.

Validation

• Locally ran appium tests.

Additional Notes

N/A

[kpchoy]

Do you have an example I can look at for how the other team is using appium?

1. So we would need to create the UI for every test we make?
2. Since this is just 1 test case and has ~100 lines, each test case would be around the same length?
3. One concern I see is that it looks tedious to manually set status for each test.

[kpchoy]

is the manual wait time still necessary? appium doesn't have a way to .wait?

[mhuynh5757]

So appium does have a way to wait, but the way I set up the test such that each test is it's own UI and each hook is it's own test run time means that appium isn't in control here. At this point, it's app code, and the appium wait is more similar to how jest waits for tests to finish since appium is the test runner.

[mhuynh5757]

Yeah those concerns are very valid. I have a few ideas on how to cut down on boilerplate, but in the end it will be pretty lengthy for each test compared to the type of testing we're used to. If you compare to how the current tests work, with a "full blown" test app and just doing e2e testing on that, it's not going to be too different in terms of total length.