Keyboard is less than 335mm wide, with feet out sits < 50mm up
Height at front
From keyboard above, 50mm under
My screen height from desk to screen (24″) is 190mm (assuming top of screen should be at my eyeline, that screen is about 20mm too low for me)
Edwards is 160mm on 1 (27″) screen and 220mm on the other (24″)
So Bezels at bottom of screens are at least 30mm (24″) and more for the 27″
So we will assume 190 + 30mm = 220mm maximum height of platform
I have > 300mm from rear of keyboard to screen which is a lot more than I expect is needed, if less depth we can alter angle more without obscuring the screen
- Adjustable angle
- Able to pull forward to user and slide over keyboard
- Non slip matting
- Soft ridge above bottom cable slot
- USB Hub under
- Cables via slots top and bottom, Micro USB & Lightning only
- Arrange micro usb on 1 side, iOS on the other?
Some commercial cloud based solutions popping up e.g. https://applitools.com/resources/
Image comparison in Automated Testing
Useful if simplistic info in below link however still using page model…
Cross platform testing example for Android and iOS using Appium
Another solution is to use the annotations @AndroidFindBy and @iOSFindBy. With this you can have the same element in the page object class with both annotations and thereby different locators for the different platforms. Example:
@AndroidFindBy(id = “btn_signIn”)
@iOSFindBy(xpath = “//UIAApplication/UIAWindow/UIAButton”)
public MobileElement signInButton;
If the app you are testing is performing the exact same way in Android and iOS then the solution above would be enough for you to be able to write a generic test that works on both platforms. But unfortunately that is not always the case.
As described in issue 2 above there are often small deviations between the platforms for performing the same task. Because of this you will need different steps for the different platforms for executing the same scenario. One way to do this is to implement an interface for each page under test. The interface define the methods used in the tests to execute the specific scenario. You can then have different page object files for the Android and the iOS pages that implements the interface methods in their own way. With this you have the solution for both issue 1 (since you have separate page object files for Android and iOS) and issue 2 (since the separate page object files can have different implementation of the same interface method used in the test).
To demonstrate this a bit more clearly I have created an example project with two simple applications for Android and iOS and a corresponding testcase using the “design pattern” described above. You can find the project here:
February 1, 2017 at 07:22 / Reply
Really a nice article found after a million searches .Tx a Lot Thomas , Between is there a way to implement web view as well since this uses APK ?
February 1, 2017 at 11:15 / Reply
Do you mean if there is a way to implement test that interact with webview elements inside your application? In that case, yes there is.
When you are using appium, you normally operate in the native context. But if your app contains an embedded webview, there will also be a webview context avaliable. You can get all the avaliable contexts by calling driver.getContextHandles() which will then return something like [“NATIVE_APP”, “WEBVIEW_1”]. If you want to automate parts of the UI that are inside the webview, you need to tell appium to switch context to the webview with driver.context(“WEBVIEW_1”). After this all commands sent by your test will apply to elements inside the webview, instead of elements which are part of the native UI. If you want to control part of the Native UI again, you then need to return to the native context with driver.context(“NATIVE_APP”).