When writing test automation, one of the well-nigh crucial constituent for determining the quantity of clip and resources you will waste (and ultimately the success or failure of the effort) is the testability of your application. By testability, I & # x27; m referring to how the app interacts with UI (and other) mechanization model, the comfort by which a trial script can setup the scenario you care to test, and how you get your tests safe for concurrency.

Making Elements Accessible

Let & # x27; s address the issue of control your application with automation frameworks first. Given that you are read this blog, it is likely you are apply either Selenium or Appium as your automation framework, so this blog post will only direct these fabric.

Web Content (Selenium)

Let & # x27; s kickoff with Selenium. In order for your web app to be easily controlled by Selenium, you need to think ahead as to how you will identify important pieces of the DOM when constructing tests. Selenium provides many substance by which you can do this, called & quot; Locator Strategies & quot;. Some are best than others. You should consider which of these you will be using in your test as you develop the user interface. Ideally, each ingredient would have an ID attribute utilize directly to the tag for any element that the test will exert.

Sometimes, for one reason or another, you may not be capable to use an ID. If this is the cause, the adjacent recommended technique is to use a CSS selector. If your web app is evolve with full principles, such as BEM (Block Element Modifier), it is probable easier to automatize as it should receive a relatively little globally unique CSS selector. If it does not, I would not urge adding a CSS family merely for automation, as it isn & # x27; t the purpose of the styling language to do automation. Rather, I would suggest that you use an HTMLdata- * dimension. You can use the CSS selector locator to catch an element by one of these attributes, but the good news is you aren ’ t adding unneeded classes to your CSS, and the purpose of the HTML attribute will be much clearer.

As for some of the other locator strategies out there, it is my opinion they should be used sparingly. If you have an Angular app, where tag names are often unique, perhaps you would use the tag name locater strategy. I would strongly discourage using XPath, as its execution across different browsers is inconsistent, which can result in outlandish tests. In particular anything using indexes, or that is heavily dependent on the brass of the DOM, is likely to be brittle, as you can expect the DOM to change as you acquire your application. I would also strongly discourage the use of locating by schoolbook as this will inhibit the ability of your tests to work in multiple languages. (e.g. & quot; Hello & quot; on American content, would be & quot; Bienvenidos & quot; on Spanish message)

Full article on XPath vs. CSS Selectors: http: //elementalselenium.com/tips/32-xpath-vs-cssCSS Selector Reference: https: //developer.mozilla.org/en/docs/Web/Guide/CSS/Getting_started/SelectorsXPath Reference: http: //archive.oreilly.com/pub/a/perl/excerpts/system-admin-with-perl/ten-minute-xpath-utorial.html

Native Mobile Content (Appium)

Making mobile apps leisurely to automate postdate similar principle to the web. In general, if you follow the accessibility guidelines set forth by Apple and Google, especially when constructing custom UI elements, you should be in pretty good shape. However, it is my experience that most apps do not adhere closely to these guidelines. No worries, if this is the case, you should still be able to make it work.

iOS Accessibility Guidelines

Android Accessibility Guidelines

iOS

For iOS, the best technique for identifying elements in the app is the accessibilityIdentifier holding on UI elements. There are 3 ways of setting this. You can add them in your XIB or storyboard utilize Interface Builder. They will appear on the & quot; Identity Inspector & quot; tab in the handiness section. However, some UI does not use XIBs or storyboards and is generated programmatically. This is not a trouble as you can telephone the[UIElement setAccessibilityIdentifier]on most UI elements. You can too add a user defined runtime attribute for the key “ accessibilityIdentifier ” in either Interface Builder or via code. This is the favorite method, however employ XPath for more complicated pieces of UI is OK, especially dynamical content such as tables.

Note that you may have heard of theaccessibilityLabel and accessibilityHintfields in the yesteryear. The problem with using these fields is that user who are using VoiceOver or other assistive device will discover the values you place hither spoken to them, so it is strongly encouraged that you useaccessibilityIdentifierinstead. You may also need to set the& quot; isAccessibilityElement & quot;belongings to& # x27; true & # x27;as some UIElements are excluded from the accessibility bed by nonremittal. Lastly, you may need to explore the& quot; groupAccessibilityChildren & quot; and & quot; accessibilityElementsHidden & quot;attributes for parent elements if you notice your element is not accessible. The easiest way to verify this is to use the Appium inspector, or the built in accessibility examiner that can be enabled in your headphone ’ s settings.

Android

For Android, the story is a bit simpler. The resource-id is the almost reliable way to identify an element (e.g.,By.id (& quot; android: id/text1 & quot;)You can find information on how to set the resource idhere. If a resource-id will not do it, so I ’ d recommend building an XPath expression that heavily leverages resource-ids. You may have understand previous steering to use the content-desc attribute for Android, but the trouble is the like as with accessibilyLabel and accessibilityHint in iOS in that users with assistive devices will hear/see the value you use hither.

For autonomous testing across multiple user personas, check out SUSATest — it explores your app like 10 different real users.

Setting Up Scenarios

As part of your tests you will ineluctably want to get the app into certain province to screen certain things. There are many techniques to go about this, and you should study how you will set up UI tests for different features in your application as they are created.

Technique # 1 - UI Automate your way to the scenario

Imagine a scenario where you postulate to make two user accounts and then perform some action in your application involve those two accounts (e.g., send a content from one to the other) Without any tools, your test will have to complete your ware & # x27; s enrolment flowing twice before attempting to send the message between the two story. This is extended and slow. When publish UI Automation such as with Selenium or Appium tests, a full rule of thumb is not to use the UI unless you are control it. The tryout for the registration flow ideally should be the one test that automates the UI of the registration flow rigorously. Automating this flow in early exam will make your tests take long and will inject more brittleness into your trial suite. However, I realize, that sometimes this is the lone way, specially when using 3rd party components.

Technique # 2 - Build a trial API

Good applications are well factored into many layers. A common layer is an API. A good API will handle all transactions that modify the business data, i.e. the front-end is responsible for display and the back-end get alteration to the datum on your servers and performs business logic and calculations.

Having an API simply for testing can greatly simplify your scripts and will increase the reliability with which they run. Imagine the previously mentioned scenario. Instead of pass the lengthy enrolment UI mechanisation two times, you could merely create an API endpoint that will generate the two accounts in the required states. Perhaps your API might even already experience endpoints that your web front-end already calls to do the same thing. Be sure to test the UI flow once in a specific test, but for follow on tests, such as the representative of sending a message, you can exactly phone the API to set up state and only test the part you care about, in this case, mail message.

Note: Please remember to secure your test API as it is likely you will create endpoints you wouldn & # x27; t want your customers to use ... (e.g., set account balance, etc.)

Concurrency

One of the biggest shipway I see developers shoot themselves in the foot is by not considering that their tests will run in parallel. You should, whenever potential, avoid publish any tests that depend on shared state in your application, and should always take appropriate step to isolate your tests from one another. It can be passing time-consuming to unravel this mess later on.

Consider the above example concerning sending a message between two chronicle. If we share the like accounts with former tests we may have a content show up that is observe by one examination, but was actually direct as part of another exam, leading to a mistaken termination. This is why screen in parallel command advance preparation, such as creating freestanding accounts for different trial.

Take another example wherein we need to examine blocking a user from our service. If we create an account for the test and then block the account, we may think we have isolated the side effects of our exam. However, imagine that if -- at some point -- we block adequate report from the same IP address, the server will finally blacklist the IP reference for the account. Now we have inclose consequence that will cause errors in other examination that will be hard to track down.

Bottlenecks and Chokepoints

Bottlenecks in automation amount to resources that tests are required to share. They can be anything from environments (e.g., servers), accounts, and IP addresses (as mentioned in the example above), or simply devices on which to execute the tests. It can be quite time consume to wholly isolate every aspect for all of your examination. To do so may necessitate a lot of time or resources. Imagine experience to reformat a device and spin up an entire environment and private net for each examination; that is quite clip consuming.

You should try to intelligently choose where your bottlenecks will be and how to manage them. For example, if you have a limit on the number of accounts for your tests, you may have to write codification to lease a test account to a test and so, when it is returned, clean and reset it for the next test. You may have to run certain test in series rather than in parallel to avoid them stepping on each early & # x27; s toes.

In a perfect world, a well-written application can be spin up instantly in the cloud. Software from cloud providers, such as Cloud Formations from Amazon, make this potential. For devices and browsers, services such as Sauce Labs can dispense any configuration you hope nearly instantly. It & # x27; s imposing to strive for consummate isolation and independence, but be prepared to do measured compromises about this as you develop your coating.

Closing

Having a highly testable coating will make writing machine-controlled tests for that covering a lots less time-consuming and a much more worthwhile experience. Creating a user interface that is automatable and conforms to vendor supplied handiness criterion, providing convenient and reasonable ways to access application states, and preparing your test cortege to run concurrently will put you off on the right foot towards achieving sustainable application stability via test automation.

I hope you launch this article helpful. Feel costless to tweet me at@ thedancuellarwith your comments.

Happy examination,

-Dan

Dan Cuellar is the Maker of the exposed source mobile automation framework Appium, and Head of Testing at Foodit. Previously, he lead the trial arrangement for Shazam Entertainment in London and Zoosk in San Francisco, and work as a software engineer on Microsoft Outlook for Mac, and early production in the Microsoft Office suite. He is an advocate of open source technologies and technical software screen. He garner a Bachelors degree in Computer Science, with a minor in Music Technology, from the world renowned School of Computer Science at Carnegie Mellon University in Pittsburgh.