How we test interaction with Facebook

Introduction

Hi, good! For quite a while now, I wanted to write an article about how testing automation is organized in Badoo. I wanted to write about something interesting and, at the same time, useful. Share experiences that can be easily integrated into almost any system. And now, such a topic has matured ...
')
As many of you know, Badoo is a social network focused on finding new friends and acquaintances. One of the most important tasks is user verification. After all, we all want the attractive girl with whom we have an appointment not to be Uncle Kolya from Tver.

We have many different ways to verify users. Some of them are quite familiar, such as verification by phone number. There is a more unusual - verification of the photo. But the easiest and fastest is verification via social networks.

This method of profile verification is possible immediately at the time of its creation - registration through a social network. First, it is fast, just one click and no additional manipulations with the phone or webcam. Secondly, it is convenient, because if you wish, you can import photos and information about yourself, instead of entering them manually.

Today I’ll talk about how Badoo does registration and verification through Facebook and how we taught selenium tests to check it.





So, imagine that you are a new user of the Badoo service. You go to the site and see this form of registration. Fill all these fields or click on the registration button via Facebook? For me, this is never a question. I would fill in all the fields manually and would not bind my account. Why? Because I'm a little paranoid, I hope this is not contagious. :)

In fact, Badoo will never place any information from a third-party source without the user's consent, so we calmly click on the dark blue button and register on the site. One click, 10-15 seconds, and we have our verified Badoo profile. Hooray!



What would a real QA engineer do after creating a profile on a service so simply and quickly? That's right, I would try to create another one. How will the service respond if you try to register another profile on the same FB account?

Open the registration page again and click on the FB icon. Nothing unexpected happened, Badoo “recognized” the FB-account and instead of registering it immediately authorized it. Everything is good.

The first selenium registration test

Now imagine that you are a QA engineer at Badoo. Your task is to automate the flow of registration and authorization through an FB account. At first glance, the task is simple, this is what you need:

• FB account;
• FB button locator on the registration page;
• the method that waits for the authorization cookie (to make sure that the test is logged into the site);
• locator sign out buttons to log in;
• the method that waits for the authentication cookie to disappear.

After the necessary methods have been written, we compile a script:

• Open the start page;
• Click the Facebook icon;
• In the opened tab, log in to Facebook;
• Wait for authorization on Badoo;
• Get the user id (let it be first_user_id);
• Log out;
• Open the start page;
• Click the Facebook icon;
• Wait for authorization on Badoo;
• Get the user id (let it be second_user_id);
• Make sure that first_user_id and second_user_id match.

So, the script is ready, you run the test and it passed. Everything is fine. It's time to insert a cat into the article:



We commit the test code to the branch, throw the task on the review and go to drink coffee. However, you did not have time to reach the kitchen, when a notification comes - the task did not pass the review, the test does not work. Something went wrong…

After restarting the test, it becomes clear that the problem is as follows - this FB account already has a profile on Badoo. Instead of registering the test immediately logged in. There is nothing to do, it is necessary to delete the profile at the end of the test. Thank God, we have an amazing thing - QaApi!

A few years ago I told you how it is integrated with our autotests. The report was called “Selenium tests. From RC and one user to WebDriver, Page Object and user pool, you can find it here - habrahabr.ru/company/badoo/blog/216255 .

In short, this is an internal api, to which from the test you can send a request and perform some manipulations on the side of the application. It is called quite simply:

QaApiHelper::deleteUser(user_id); 

Of course, QaApi can work only with test users and is available only through the internal network.

When the test learned to remove the user for himself, he began to work stably and perfectly. But it was not so long.

Badoo testing stages

We tell about what stages of testing exist in our company at almost every conference. Here I will briefly list those that are interesting from the point of view of selenium tests:

• Testing on the dev-environment. Devel is a copy of production with its bases and internal services.
• Shot testing. A shot is a production environment that is accessible from the internal network at a specific urla and is the merge of the master code and the task being tested.
• Testing on staging. Staging, traditionally - this is the result of the merge of the release branch and the wizard.
• Production Testing.

Initially, we drove the tests on the environment-setting and staging. However, over time, they came to the conclusion that tests need to be able to drive on shots. The reason is quite simple - the dev does not always copy production perfectly, and it’s bad to catch a bug on staging and roll back the task from the release. This means that the task in this release will not fall and will leave later than planned.

Second selenium registration test

Let's return to our test. Imagine that you are still the same QA engineer who now faces the task of teaching the registration test to work in parallel on several shots and rating.

Let me remind you that the shots work in a combat environment, that is, they have one user base. It is quite obvious that in the current implementation it will not be possible to run tests in parallel. If you run these two tests with a difference of a couple of seconds on different shots, the second one will try to create a profile on Badoo when it’s already created by the first one, and will inevitably break:


How to solve our problem? How to make the test always has a fresh FB user?

At first, I tried to solve the problem as minimally as possible. I created a mysql tablet, into which I added some FB-users created by hands and put statuses on them - they are free. The test took the user from this plate, changing his status to “busy”. If there was no free user, the test fell with the appropriate message.

This system had several obvious drawbacks. First of all, if too many test instances were running at the same time, there were not enough accounts and there was nowhere to take them. Also, the test could for some reason not free the user at the end (for example, if he was stopped by pressing “Ctrl + C”). None of this made us happy in the morning, when there was less than an hour before the release.



Pretty quickly tired of unstable crashes and uncontrolled states of FB accounts, I began to look for a better solution ...

The Graph API

Facebook has a great api that allows you to create test users and manipulate them - developers.facebook.com/docs/graph-api . It is organized quite simply: we form the necessary request and send it to the FB server, the answer is returned in json format.

An example of a request that will register a test user with the name Alex:

https://graph.facebook.com/{APP_ID}/accounts/test-users?name=Alex&access_token={APP_ID}|{SECRET}


We receive the application id and secret by registering our application on the FB (for details, see developers.facebook.com/docs/facebook-login/overview ).

This pool of Facebook users

Well, let's create users! :)



Having carefully studied the graph-api and its features, we have compiled a list of nuances:

• The number of registrations per application is limited. Quote: "For each application, you can create up to 2000 test users.".
  Conclusion: you need to keep records of created users.
• The newly created test user can only interact with a single application. In this case, the application is the domain on which the service is located. In Badoo, staging and shots are on different domains.
  Conclusion: keeping track of users, you need to separate them by app id.
• User logs in rather slowly. On average from 2 to 5 seconds.
  Conclusion: it is more convenient to have a previously created FB user so that the test does not waste time creating it.
• The test must deal with an account that is probably not used in any other test to avoid the fluctuation race condition.
  This item is important as part of the test described here.

Total: it would be cool to have a custom pool of FB users that would fit our “Wishlist”. In fact, it should be a sign that will contain the following information:

• User ID;
• Email;
• Password;
• App id;
• App Secret;
• User status - busy test or not;
• Timestamp creating user.

In addition to this tablet, we needed several scripts.

The first is looking for users in our pool who are busy for more than N minutes and marks them as free. This is done so that users can be used not only in the test (where you can register a guaranteed user unlock upon completion of the work), but also for manual testing.

The second solves the problem of a long user creation on the side of facebook. It looks like this:


We wrapped the receiving FB user into a special QaApi method. The test refers to him for a free user. If not, a special task is created. As part of this task, the script sends a curl request to graph-api, waits for a response, and writes down a new user to the nameplate. The test receives an answer - “must wait”, closes the connection and makes another attempt after a few seconds. So we solved two problems. First, the logic of working with graph-api is separated from the logic of tests. Secondly, the tests do not keep long connections to third-party services, which greatly facilitates the debug of any problems associated with an increase in the time to pass the tests.

Next, we rewrote the necessary tests for a new system for obtaining FB accounts and left the tests to run overnight with our CI server (we use Teamcity). By morning, the result was ready. There were exactly as many users as needed for use in tests.

The pool has a fairly user-friendly method interface. It allows at any time to get the ratio of free users to total for each application, to get the number of users created by date. This helps control the pool balance when adding a new test using FB accounts.

Is there such a convenient API for other social networks?

I was interested in the guys from VKontakte:


And the guys from Odnoklassniki:


Total

At the moment, the pool is an integral part of our system. New scripts and new methods have appeared around him. Due to its flexibility and simplicity, the system is convenient to develop and control.

A little about what happened in the end:

• A handy tool for manual and automated interaction of Badoo with Facebook;
• More than 20 unique tests using the facebook account pool: registration / authorization, verification, uploading photos from an FB account, searching for friends on Badoo, sharing of awards, and so on;
• In the pool, there are 9 different applications that use a total of approximately 1.5k active users;
• QaApi-methods can create FB-accounts, make them friends, upload a photo to them, associate FB-accounts with our test users;
• The system itself supports the required number of FB-accounts and most often does not require any manual intervention.

For more than a year of use, api worked stably. Only once there was a problem with user tokens, but facebook developers fixed it pretty quickly. Who is interested in more details - developers.facebook.com/bugs/1662068220677444 .

In conclusion, I would like to thank our guys from the design for their invaluable help in creating the whole system. You are great!

Thanks for attention!

Vitaly Kotov, QA-automation engineer.