General Testing Suggestions

These suggestions aren't specific to the page object pattern and are useful no matter how you chose to architect your tests.

Make each test self contained

Every test in your test suite should be able to run on its own without depending on any other tests to successfully run beforehand. Every test should start with a clean slate, as if the app was just installed on the phone.

For example, you should not have a single test that logs in to your app at the beginning of your suite and then have every subsequent test assume that the app is already logged in. If the log in test were to fail for any reason, every other test in the suite that relied on it would also fail.

In order to save on valuable time, you can use backdoor methods to speed up repetitive setup tasks like logging in. You can also use backdoor methods to reset the app and put it in a particular "clean" state before each test starts.

Split tests up into small chunks wherever possible

Long tests are just as bad as interdependent tests. If the first part of a long test fails, then it won't finish the rest of the test.

For example, it's better to have one test to log in, one test to search for an item, and one test to purchase an item. This way, with three separate tests, even if there is a bug in the search feature you can still test the purchase feature.

Backdoor methods can, again, provide a fast way to skip some parts of a long process and put the app into a certain state. For example, you could use a backdoor to add a product to your shopping cart before running a check out test.

Be as deterministic as possible

• Avoid branching on UI state - Your test should expect a certain UI state and assert that it is as expected rather than querying the UI to determine the next step.

• Avoid branching in general (if, else and try, catch) - These are warning signs that you are not being as deterministic as you could be. They can be useful in certain situations, but be conscious about whether or not you can use an assertion instead.

• Be careful with loops, especially the while loop - Make sure you don't have loops that will run forever if something goes wrong with your app. Limit them to a reasonable number of iterations.

• Try not to use Thread.Sleep(int) - WaitForElement and related methods provide a much better alternative. The only exception to this rule is when you have an animation that needs to complete before you want to interact with any elements.

• Try not to do anything randomly - Test results should be repeatable between test runs, randomness inherently takes this away.

• Use assertions liberally (WaitForElement, WaitForNoElement, and Assert) - We write tests to confirm app behavior, assertions are essential to confirming conditions. Best practice would be to have an assertion after every action.

• Take many screenshots - In Visual Studio App Center, screenshots are the best way to see every step of a test's execution and visually identify bugs. Best practice would be to take a screenshot following every assertion (i.e. take some action, make an assertion, take a screenshot).