[appium学习笔记]writing maintainable UI test automation

​

what defines a high quality test?

​​​​​​​
1.only fails when the SUT fails
2.easy to read
3.fast and reliable

what defines mantainability of tests?

1. changes are not frequently needed
2. changes are easy to apply
3. changes to SUT don’t break your test scenario
4. if a change to the SUT breaks a test, it has no butterfly effect on all the tests(each test only tests one specific attribute of the SUT)

how to minimize the impact of change?

1. use stable control locator strategy​​​​​​​
   • Accessibility id
     • iOS: accessibility id
     • android: content-description
     • windows: AutomationId
   • XPath: stop using XPath! It is extremely fragile!
   • UI Test Recorders: don’t use them, they generate very fragile tests
2. minimize repetition of code
3. minimize the things tested by one test case
4. create abstraction bewteen the test and the SUT

patterns & practices for maintainability

1. don’t repeat yourself(DRY)
   • stop copiying and pasting code, avoid repeating patterns that we use over and over again, move them either to a class or a method)
2. single responsibility principle
   • when you write a class, then this class should only be responsible for one thing only
3. page object pattern
   • for each screen/page create a class that abstracts the interaction with the screen/page
   • for each action create an action method that returns a page object
   • for each verification create a method that executes the verification and returns true or false
4. descriptive and meaningful phrases(DAMP)
   • read the code as if it is a sentence
     

SOLID priciple

S: single responsibility principle
O: open/close principle(create a base class in such a way that when you inherit from the base class, your class is open for extensibility but close for modification by the inheriting class)
L: liskov substitution principle(objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program)
I: interace segregation principle(create specific interfaces that get implemented by concrete classes)
D: dependency inversion principle(you should only depend on abstractions -the interfaces, instead of the concrete implementations)

​