Mobile phone testing platform


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

Design points:

  • 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?

Appium cross platform

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:

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 ?

Thomas Hansson
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”).



Automated testing -> Useful short version


  • Hamcrest matchers
    • replace asserts
    • high degree of complexity
    • easy to understand
    • plain (useful) logging?
    • Examples:
      • allOf – matches if all matchers match (short circuits)
      • anyOf – matches if any matchers match (short circuits)
      • not – matches if the wrapped matcher doesn’t match and vice
      • equalTo – test object equality using the equals method
      • is – decorator for equalTo to improve readability
      • hasToString – test Object.toString
      • instanceOf, isCompatibleType – test type
      • notNullValue, nullValue – test for null
      • sameInstance – test object identity
      • hasEntry, hasKey, hasValue – test a map contains an entry, key or value
      • hasItem, hasItems – test a collection contains elements
      • hasItemInArray – test an array contains an element
      • closeTo – test floating point values are close to a given value
      • greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo
      • equalToIgnoringCase – test string equality ignoring case
      • equalToIgnoringWhiteSpace – test string equality ignoring differences in runs of whitespace
      • containsString, endsWith, startsWith – test string matching


Serenity Test Automation

Focus on screenplay pattern:


Reminder on ‘SOLID’:


The first five principles are principles of class design. They are:

SRP The Single Responsibility Principle A class should have one, and only one, reason to change.
OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.
DIP The Dependency Inversion Principle Depend on abstractions, not on concretions.


Thoughts on Page Model

Page model alternatives:

“Journey” or “Screenplay’ pattern

A weak Journey example:



State modeling: