configuration parameters
During the introduction section, we have went through the list of configuration items available in the crawler.config.yml file:
crawlingConfig:
platform: 'ios' // platforms to run: android, ios, pc-web
testingPeriod: // maximum testing period for a crawling task, after which the task will terminate
testingDepth : // maximum testing depth of the UI window tree, exceeding which 'Back' navigation will be triggered
newCommandTimeout:// time interval takes to examine current window source after a crawling UI action has been performed
launchTimeout: // time interval to wait after app has been launched.
maxActionPerPage: // max UI actions filtered and performed per-page, this will provide great memory optimisation and prevent an Page for staying too long
targetElements: // array of hight priority UI element to perform
asserts: // provide for regex assert test cases for windows
exclusivePattern: // specify the pattern hence you can let those element which contain the regex pattern be excluded from execution
clickTypes: // specify the types of UI element which can handle click events
editTypes: // specify the types of UI element which can handle edit events
horizontalScrollTypes: // specify the types of UI element which can handle horizontal scroll
tabBarTypes: // specify the types of UI element may act as a control widget in master-detail pattern
exclusiveTypes: // specify the types of UI element in which all the sub-views will be excluded from scanning and crawlHere we will dive into detail and explain on the meaning and example for each of the configuration items.
platform:
Specifies which platform the crawler is crawling on, different platform has different driver layer data models provided in Macaca infrastructure libraries. In Mcacaca-Nosmoke app crawler, the program will based on the chosen platform to erase out the difference between each platforms and conduct crawling based on a unified data model.
values:** **
android, ios, pc-web (case insensitive)
testingPeriod:
Maximum testing period of the crawler program can execute before it is terminated. The **termination of crawling ** is decided by the following factors:
- The crawling process sticks on a certain page after all of the page's action has been performed and navigation back does not work
- The crawling process is now on the root node of the entire crawling tree and all the page's action has been performed, which means the entire tree can not proceed for further crawling.
- The crawling process times over, **which provides a rescue strategy in case the crawling logic last forever and fails to recognize the root node based on the digest of the root. **the default interval is 30 mins.
example :
testingPeriod: 1800 // unit is in seconds
testingDepth:
Since the the app crawler is based on a DFS tree algorithm, in some extreme condition like the crawling process for an super app, a simple detail view may hide inside of deep layers of UI navigation. Uncontrollable of sizes of the crawling tree will make direct impact on memory and performance on the hosting machine. Hence you can use the testingDepth to limit the depth of the tree. Together with the maxActionperPage,you can decide the overall size of your crawling tree. The default depth is 8
example :
testingDepth: 8 // the crawling tree should not exceeds a depth of 8
newCommandTimeout:
For each of the action performed, the target app UI may need some extra time to response for it. The newCommandTimeoutgives you the chance to set for it, the default interval is 4 seconds.
example :
newCommandTimeout: 3000 // unit in milliseconds
launchTimeout:
When the crawler start up an application, there might be some time interval needed before the app fully resumed into the foreground, sometimes the time interval varies between host machines. The time interval needed by some low profile server is much longer than a new model of personal mac. The launchTimeout gives you the chance to set for it, the default interval is 8 seconds.
example:
launchTimeout: 8000 // unit in milliseconds
maxActionperPage:
As what has been mentioned at testingDepth we need to limit the size of the tree data in order to guarantee its performance. testingDepth limit the depth of the tree and here the maxActionperPage limit the action items (potentially lead to a new UI view) of a single crawling view node. You can understand as it effectively limit the width of the tree.
example:
maxActionperPage: 20
targetElements:
Since the crawler's design goal is to parse a view in xpath format, UI actions are conducted in random order by default. In some specific page, there might be only some UI actions you want to trigger and ignore the rest, for example, in login and register, and event in case you want to terminate by click the logout button and ignore the rest of the element in that page.
example:
targetElements:
loginAccount:
searchValue : 'please input username' // element's: default value/ text value/ id / name. any of above
actionValue : '中文+Test+12345678' // if the element is an input, actionValue is the input value
loginPassword:
searchValue : 'please input password'
actionValue : '111111'
loginButton:
searchValue : 'Login' // if the element is an button, there is no need to specify the action value
alertConfirm:
searchValue : 'yes'
asserts:
Assertion is a must have function in order to let NoSmoke fulfil its duty as a CI smoking test utility. In the development plan we are planning to support multiple types of assertion. (using text as regex check and scan and recognise the existence of an image under view)
example:
asserts:
- type: 'regex' // types of assertion, so far we support 'regex' here
given: 'android\s+bootstrap' // trigger condition of the regex check
then: 'please\s+input\s+username' // the assertion criteria of the regex check
- type: 'regex'
given: 'HOME'
then: 'list'
clickTypes:
Help the crawler to recognise which element can be click. The click types depends on each of the platform's UI framework.
example:
clickTypes:
- 'StaticText'
- 'Button'
editTypes:
Help the crawler to recognize which element can be edit as input. The edit types depends on each of the platform's UI framework.
example:
editTypes:
- 'TextField'
- 'SecureTextField'
tabBarTypes:
TabBar is a special case the crawler meet. The reason is that in a master-detail view pattern (tabView for example), the window contains actually two layers of node, the first one is the tab bar and the second layer is all its tabviews. If you don't specify the tabBarType and help the crawler to recognise the view pattern, the crawler tab is sorted as a normal action and there is no guarantee that each of the tab's action can be fully performed.
example:
tabBarTypes:
- 'TabBar'
exclusivePatten:
During the crawling process of the entire UI source, there may some disturbing UI elements which will bring some undesired outcome and affect the crawler from normal execution. For example: an button which will pop you to the system's setting panel, the crawler will enter the system's configuration panel and continue operation, which might not be what you expect. You can exclude all those UI element by set an blacklist text pattern.
example:
exclusivePattern: 'pushView|popView|cookie|userAgent:|Mozilla|cookie:|setTitle|Macaca Test Swipe API'
exclusiveTypes:
In some cases, you just want to get rid of a specific UI classes, for example you don't want the crawler automatically touches anything on the navigation bar (because it will easily break the navigation chain :D ), you can simply specify the element class type in the exclusiveTypes
example:
exclusiveTypes:
- 'NavigationBar'