 So welcome everyone to the session challenges in testing social networks by Anna Baza. We are glad they can join us today. So without further delay over to you Anna. Hi, welcome everyone. Yes, so I've been wondering if you if you ever have been asked, can you integrate the automated UI test into into cloud can we do it a part of the pipeline. And I was like yeah I got this you know everything works locally and we can integrate it. And then the reality was kind of brutal when when everything went into cloud, everything start to falling apart. So basically, the whole presentation today will be about my journey of challenges in testing the social network. But before we dive into that, I would like to introduce myself and tell a bit about what I'm doing. So I'm lead productivity engineer at wolf. I'm also a admin design lead and a project manager at Anita be open source. I've been finalist in woman in tech excellence hours, three times as a digital leader of the year for diversity and includes inclusion initiative of the year, and as a hero of the year. I'm also a senior member of I triple triple E. I'm a bit about the words online festival. The app which we are doing is actually audio stage social network where you can jump into stage you can you can share your show you can share your music you can, you can sing you can do the stand up you can be a Canadian. But on top of that, we got a social network connected to the stage, and the people can interact they can react on your on your entertainment presentation or whatever you're doing there they can comment it they can talk to each other. With the social network, there is a plenty of plenty challenges when it comes to you I testing. We identify few of them. So one of them is parallel testing with unique credential so if you can easy imagine if I write my test and I got unique user credentials baked into the tests, then if I run them parallel as in a in a several devices in a cloud. It might clash with each other. The interaction wouldn't be be good. Sometimes we get like arrow, you sign up, sign on somewhere else. Another challenge which we identify at wolf was testing event based behavior so events are the type of actions which are not done by the user itself, but rather but by other users or bots like I would like to test it. Talking to me does the does the message is displaying correctly. If I'm getting 100 messages do I get the batch with the proper number and things like that. The other thing which we identified as a challenge was a testing huge events, and this is. This is very interesting because the testing huge events is a very intense communication between between client and a server there's lots of going on loads of messages appearing and testing it is is kind of kind of a challenge but also manual test doesn't really we can't really replicate this kind of things in manual testing so if something happened on a huge event. It's important that we can we can identify the issue so so someone could fix it. And then the last thing what I will be talking about is testing unique base scenario so the things which are happening in our applications just once like whenever I'm registering with associated account like Facebook or Google. And I would like. I don't want to create the new account every single time I run the test because it's impossible so I will be talking how did we solve those issues at wolf. Now. This challenge testing unique user credentials so whenever I'm registering sorry. Whenever I'm logging in as a user I don't want to conflict with other running tests at the same time. What we did actually we build our own testing farm and this the building on testing farm gives gives us amazing flexibility that we could actually run a self hosted agents and assign a single agent to the single device. And then in the in the environment, we could encapsulate that this single device got a single credentials. So, so we actually our, our tests whenever they are assigned it to the agent and device they running in parole but they do not conflict with each other because the users are different. Challenge number two testing unique scenarios so whenever I want to register myself with associated account. But before we dive into that I need to do a slide recap of what is client server architecture in a nutshell. So, we generally in a client server we use two types of the communication, we used restful API, which are just simple client, which is our app is asking something to the server, and a server is giving the response to that request. Another type of the communication is a socket socket subscription. So the client is subscribing to specific socket, and it says I will be listening if something happening on that socket so from that moment on that the connection is established directly between client and a server. The server can can send the messages directly to the socket, but then the client is actually capturing the messages. So the idea for that is just before because when we, when we have apps like, like chat. We would like to see exact moment when other users are writing something or they, they published something. And in terms of that we don't want to ask the server every 100 milliseconds to get the same user experience. Is anything new on that chat or any other chat. That would very quickly overflow our servers, especially we has, we have at Wolf we have already passed million users so million users 100 times times 10 times at the second that 10 million 10 million request every every second that's just too much. So, generally, this to communication will will required the further understanding of what we've done in terms of our testing. So, what we've done on our self hosted computers, we actually mounted a proxy, and our automation system is building a client, and it says, hey, instead of connecting to the server, you will be connecting to the proxy. And a proxy is a is a kind of a server which actually is just the middle part between the connection to the real server. So the client is sending the request to the proxy proxy is sending request to the server, and then the response is back to the proxy and a proxy is giving back the response to the client. And thanks to that, we can actually record whatever has been whatever communication has been has been done between the client and a server and we can store it we can encapsulated specific test. And thanks to that, we can replay the unique scenario of user registering as a with the associated account without actually bothering the server asking if that user exist or not, because we got whole communication with a request and a responses. So we can just reuse it. This, the third challenge, which we have identified is testing event based scenarios and an event based scenarios is like I said earlier is just receiving the messages from other users or likes or any other interactions which comes from other users and we want to see it constantly. And this is the one which which goes through the socket subscription. So, again, we did the same pattern, we said this at this time, we said that that actually server is the proxy is listening to the server and a client is listening to the proxy. So whenever server is sending the event that someone has sent the message to our chat which we are listening, the proxy would listen to that and then we send it to client, and then we can store that that the message that the event has been has been sent and then whenever we want it, we can just reuse it. So in that, in that case, when I think about the user case of the test itself, it's, I'm logging in, obviously I'm going navigating to the specific chat, and then I'm asking from from the actual Appium code, I'm asking the proxy to fire a very specific event and this event is read from the local but database and it's fired directly to the client. In that case, we are encapsulating receiving the messages in a way that this, this very device is receiving the messages but no one else in the world because it doesn't actually happening on a on a real server. It just, we just really pretend this environment of the server. And the challenge number four, testing huge events. That one is, is generally very, very complicated. It's much complicated than, than what we seem before, because we would. We would register everything. All the requests and responses so all the restful API's would be would go through proxy and all the events would go through proxy and everything would be stored in a, in a persistent database. So, so we can reuse it when we need to, but because those events, they actually happening in a in sort of synchronized manner so the user have to be in a specific chat to receive the specific messages. This has to be reviewed very, very carefully so we could actually replay that on an Appium. And whenever all that work is done, and everything is good, you know, the working established the test are passing it's great. We having a real, real value of what we've done, then everything starts over again, because someone changed the UI. And I believe many of you have been in that position that UI has changed and we need to write the tests again. That's it from me. Thank you very much. And I would like to listen if there are any questions. We have one question from Anand. He's asking how is this proxy implemented. Right, so for proxy. I've used Node.js JavaScript, obviously, and I've used MongoDB as a persistent database storage. I use Express for the server. I use circuit.io for the listening to the specific circuit and firing the events. And that's pretty much it. Okay, there's one more question. How often do you have to update the recorded request or response data? Yes, that's a very valid question. So it depends on what test we are doing. Some of the communications, they do have timestamps. And when it does have timestamps, we need to record it quite often. Usually, we're aiming to record once a week, but some of the events are actually pre-recorded and then reused because they are unique. So we don't re-record them ever. They are like a static part of the system. Okay, and Kamal wants to know if there is any sample code available? Sample code. Well, we do not have public repository, but what would you be interested in? Is it a proxy or the communication between the proxy and an apium? What would that be interesting? Kamal, could you elaborate what is the need? Okay, so for communication between the proxy and the apium, we are using, for our test, we are using C-sharp. And the communication is a simple RESTful API connection. So I'm just, instead of asking somewhere else, on the proxy level, on the device I'm asking, hey, can you give me local host's message and then whatever the details of the message or event and the details of the event. And then our server got the endpoints, which actually listen to that request and if it is. Right, maybe a bit of recap how we're doing it. So for every single device, there's a single proxy and a single apium server running. So the apium is connecting directly to specific proxy asking, hey, can you send the message XYZ or event XYZ and then the proxy checking the database and sending the event XYZ. That's how it's done. I'd just like to take a moment and thank you, Anna, for a wonderful session. Thank you, Anna. Thank you.