Welcome back to the testing universe! In the recent article, I have shown you how to prepare tests for AppCenter. Today I want to share with you a bunch of tricks that will make writing tests easier, faster and more enjoyable. From my experience, I can tell you that there are few things as enjoyable as the smooth testing process so let’s do what we can to make this state a routine!

 1. „Device sets” setting

You probably know how slow choosing proper devices can be. This set comes to the rescue - you'll save some time.

It's worth knowing that you can use such set in several projects. That's why it's good to choose a dozen devices and then use them for tests faster.

To set this option, choose a tab called "Device sets" on the left panel. Then click on "New device set" and add devices you need.

 

After choosing the proper number of devices, add a name in the field "Set name:" and click on "New device set".

To use a brand new set, in tests create a new test (inception!) and in the first step choose a set of devices built before.

 

2. Fast tests running

During running tests, you don't have to copy a path to the project or apk file every single time. If you don't create a new project, paths remain the same. To make your work easier, save the whole with all the necessary paths to the notebook once and paste it to the console to run a test.

Fine, everything is clear now. But what to do if you want to change devices? All you need to do is to replace the fragment marked below and put on the console.

 

 

By transforming the mentioned part, you change only the list of devices on which you are running test.  Instead of aggressive clicking through the folders and endless paths copying, you modify only one small thing in a way more pleasant and easy way.

 3. How to navigate in a project fast? How to write a basic testing scenario?

Your PM has already incorporated you to the new project, and you must do tests for AppCenter ASAP? Need to start navigating in views fast? No worries, I have lifesaving tips that will save the testing and your nerves.

First, search for phrases from the app, e.g., "Log in" button, so now use CTRL+F and type whatever you're searching for.

DISCLAIMER: I'm testing an app with Polish language, "Log in" = "zaloguj się"

 

 

As you can see, the phrase "zaloguj się" can be found on the login page („LoginPage.xaml”). If it appears in only one place of the project, the problem is almost solved. To click on the element to test, use the line of below code:

app.Tap(x => x.Marked("ZALOGUJ SIĘ"));

Then just give it a name using „AutomationId”. Remember to put the id in the right place (again, text on the given page will help you). To add it, type:

AutomationId="Test"

Then, using app.Tap type the code responsible for clicking on the element (as I presented above).

Good job, you're almost done! Type the text in inputs. You can say "I did tests" only if you complete data. Check out the example below:

app.EnterText("Login", "MyLogin")

The first word is the name of the field and the second argument is your input. You read it in the following way: For the "Login" field, type "MyLogin".

Last but not least, screenshots. You get what's going on in the code, but the Client usually doesn't. How and when you should make them? Different devices you're testing the app on, have different units. There are huge chances that app will run slower on some device, at some point. To avoid this situation, you can secure yourself easily. At the beginning of tests, type:

using System.Threading;

Thank this library, you'll be able to use a pause in the project later. An example: you log in to the app and want to make a screenshot of the dashboard main screen.

app.Tap(x => x.Marked("ZALOGUJ SIĘ"));
Thread.Sleep(2000);
app.Screenshot("Dashboard");

Command your test to click on the login button after filling in the data. Later, "sleep" will cause 2 seconds (2000 ms) delay in making a screenshot. Sleep saves you from screenshots of loader before logging in. Weaker devices can load longer, so it's better to to give them some more time.

4. Several testing paths in one test

So you want to make this vast test, but you're afraid that it will fail at some point? I have a solution for that, too! The answer is: several individual categories in the test.

Create the test and its category, for example, "Telegram". Remember that every category equals individual application running. To enter Telegram, go through Login -> Dashboard -> Telegram.

 

 

 

In every individual category, usually, you must go through these first two screens (Login and Dashboard). The only con of this solution is the duration of the running of the test. The possibility of testing every path individually is salvation. You don't have to create one enormous test consisting of more than 100 lines, that drives you insane from the very beginning.

Several smaller test categories give you more control over the testing process. If something goes wrong at the start, you can skip that part, move on, test the rest of the app, and get back later.

 

What are your testing hack? What makes your work easier? Let us know in the comments!